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Die f olgenden Angaben sind den vom Anmelder eingereichten Unterlagen entnommen 

(g) Chipkarte und Verfahren zur Verwendung der Chipkarte 

(§) Chipkarte, die zur Durchfiihrung von Transaktionen 
dient, bei denen geldwerte Einheiten oder andere nicht- 
monetare AnsprOche reprasentierende Wertdaten zwi- 
schen dem Karteninhaber und mindestens einem Trans- 
aktionspartner (Service-Provider) Obertragen oder dem 
Service-Provider zur Verifizierung der Ansprijche vorge- 
wiesen warden, wobei die Chipkarte einen Speicher um- 
fafSt, in dem zur Durchfuhrung der Transaktionen erfor- 
derliche Oaten abgespeichert werden, und die Chipkarte 
ferner folgendes aufweist; eine Einrichtung zum Laden 
von einer oder mehreren Kartenanwendungen (VAS-App- 
likationen) auf die Karte, die jeweils die Durchfuhrung von 
Transaktionen zwischen dem Karteninhaber und einem 
Oder mehreren Service-Providern ermoglichen. 
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Beschreibung 

Die Brfindung betrifft eine Chipkarte, ein Tenninal zur Venvendung mil einer Chipkarte, ein Verfahren zur Verwen- 
dung der Chipkarte sowic ein Chipkartensy stern, 
s Es sind bercits Mikroprozessor-Chipkarten luit Zalilungsliinkiion, z. B. elektronische Geldborsen, ec-Cash, Kredil- 
funktion usw., iiii Einsatz und es sind je nach Auspragung durch Organisalionen, wie ZKA (Zentraler KreditausschuB), 
VISA Oder EMV (Europay Mastercard VISA), Vorgaben festgelegt, so daB sie als Zahlungsniittel ("Geldersatz*') ver- 
wendet werden konncn. Als beispielhaftc Beschreibungen seien hier genannl: 

10 - ZKA, Zentraler KreditausschuB, "Schnitlsiellenspezifikation liir die ec-Karte mil Chip", 27.10.1995; 

- Europay International, "Integrated Circuit Card, Specification for Payment Systems, EMV'96*', V3.0, 30-Jun- 
1996; 

- TSO/TEC 781 6-4 "Information technology - Identification cards - Integrated circuit(s) cards with contacts. Part 4: 
Interindustry cominands for interchange", 01-09-1995; 

15 - prEN 1546-1, "Identification card systeins - Inter-sector electronic purse, Part 1: Definitions, concepts and struc- 

tures", 15.03.1995; 

- prEN 1546-2, "Identification card systems — Inter-sector electronic purse. Part 2: Security architecture", 
03.07.1995; 

- prEN 1546-3, "Identification card systems - Inter-sector electronic purse. Part 3: Data elements and interchan- 
20 ges", 09.12.1994. 

Ein aktueller Uberblick uber Chipkarten ist zu finden in: 

- Stefan Schutt, Bert Kohlgraf: "Chipkarten, Technische Merkmale, Normung, Einsatzgebiete", R. Oldenbourg 
25 Verlag, MunchenAVien, 1 996, ISBN 3-486-23738- 1 . 

Hcrkommlichc Chipkarten sind rcgclniaBig nur fiir cincn bcstimmtcn Anwcndungszwcck, bcispiclswcisc als elektro- 
nische Geldborse oder als elektronischer Ausweis, nutzbar. Die auf diesen Chipkarten aufgebrachten Anwendungen sind 
jedoch regehnaBig statisch, d. h. sie werden bei der Herstellung der Chipkarte aufgebracht und bleiben iiber den Lebens- 
30 zyklus der Karte hinweg unveriindert bestehen. 

Herkommliche Chipkarten sind also sowohl hinsichtlich ihrer Variabilitat als auch hinsichdich ihrer Funktionalitat be- 
schrankt. Insbesondere sind herkommliche Chipkarten nach dem HerstellungsprozeB hinsichtlich ihrer Funktionalitat 
festgelegt und nicht mehr veranderbar. 

Es ist daher eine Aufgabe der vorliegenden Erfindung, eine Chipkarte zu schaffen, dereii Funktionalitat variabel ist. 
35 Eine weitere Aufgabe der Erfindung besteht darin, eine Chipkarte zu schaffen, bei der die Zahl und Art der mit der 
Chipkarte durchfuhrbaren Applikationen bzw. Anwendungen und Transaktionen auch nach dem HerstellungsprozeB 
noch variabel ist. Es soil moglich sein, auf diese Chipkarte zusatzliche Apphkationen "zu laden", es sollen Applikationen 
von der Chipkarte geloscht werden konnen und die einzelnen Applikationen sollen daten- und sicherheitstechnisch un- 
abhangig voneinander definiert sein und unabhangig voneinander ablaufen. 
40 Die Chipkarte soil beispielsweise die daten- und sicherheitsiechnischen Voraussetzungen nach ISO 7816 erfullen; die 
einzelnen Applikationen der Karte sollen jedoch insbesondere von der Kartenplattform selbst unabhangig sein. 

Es ist eine weitere Aufgabe der Ei*findung, eine Chipkarte zu schaffen, bei der der Benutzer die Anzahl und Art, der in 
seiner Karte verfiigbaren Applikationen selbst bestiinmen bzw. zusammenstellen und andern kann. 

Es ist femer eine Aufgabe der vorhegenden Erfindung, eine Chipkarte zu schaffen, mit der sowohl Intraservices (d, h. 
45 geschlossene Applikationen in dem Sinne, daB keine Abrechnung und Leistungsubertragung mil extemen Partnern zu er- 
folgen hat) als auch Interservices (d. h. Applikationen mil zusatzlichen AuBenbeziehungen zu externen Partnern) ennog- 
licht und durchgefuhrt werden konnen. 

GeinaB einein Aspekt der Erfindung ist eine Einrichtung voigesehen, mit der eine oder mehrere Kartenanwendungen 
auf die Karte geladen werden konnen, mit denen jeweils die Durchfuhrung von Transaktionen zwischen dent Kartenin- 
50 haber und eineni oder mehreren Service-Providem ermoglicht wird. 

Durch das Laden wird die Chipkarte so konfiguriert, daB sie eine neue Funktionalitat erhalt, d. h. eine ApplikaUon aus- 
fiihren kann, die ihr bisher nicht moglich war. Durch die geladenen Daten werden Applikationen definiert und in Verbin- 
dung mit den Grundfunkfionalitaten der Karte wie et wa dem BeLriebssystem reafisiert, die vorher nicht auf der Karte vor- 
handen waren. Damit wird die Funktionalitat der Karte durch das Laden einer Applikation urn eben diese Applikation er- 
55 weitert. 

GemaB einem Ausfuhrungsbeispiel der Erfindung ist auf der erfindungsgeinaBen Chipkarte eine Datenstruktur 
(DF_VAS) vorgeschen, die selbst wiederum in eine Teilslruktur und einen Definitionsdatensatz unterteilt ist, wobei die 
Datenstruktur mittels einer sie identifizierenden Kennung eindeutig identifiziert ist und somit von der Kartenplattfomi an 
sich unabhangig ist. In die Teilstruktur konnen nun sogenannte Applikationen geladen werden, d. h. Funkfionalitaten 

60 oder Anwendungen der Chipkarte. Damit wird es durch Laden einer bestimmten Applikation der Chipkarte moglich, 
Transaktionen zwischen dem Karteninhaber und einem fiir diese Applikation spezifischen Service-Provider durchzufuh- 
ren. Ein Definiuonsdatensatz innerhalb der Datenstruktur enlhalt Infomiationen fiber die Art und/oderdie Sirukiur der in 
der Teilstruktur geladenen Applikationen. Zumindest der Definitionsdatensatz, vorzugsweise jedoch die gesainte Daten- 
struktur sind mittels mindestens eines Systemschlussels gegen Modifikationen abgesichert und nur unler Verwendung 

65 dieses Schlussels modifizierbar. Anstelle eines Systemschlussels sind auch andere Sicherungsmechanisnien oder Siche- 
rungseinrichtungen vorslellbar, mittels derer die Absicherung gegen Modifikationen erfolgen kann, etwa durch eine per- 
sonliche Kennzifler (PIN) oder sonstige zur Absicherung dienende Einrichtungen. 

Mit der obigen Struktur ist es moghch, in die Teilstruktur verschiedene Applikationen zu laden und diese auch wieder 
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aus der Teilslruklur zu loschcn, so daB die Karte hinsichtlich ihrer Funktionalitaten bzw. der mil ihr durchliihrbaren An- 
wendungen variabel isl. Laden und Loschen von Applikalionen geschiehl durch Schreiben von applikalionsspezifischen 
Daten und Schlusseln in die vorhandene Teilslruklur. Durch Vorsehen des Syslenischlussels und der Daienslrukturken- 
nung wird die die Mullifunktionalilal eniioglichende Datenstruktur unabhiingig von der Kartenplaltfomi an sich und 
auch hinsichllich ihrer Sicherheitsarchiteklur sclbsUragend und unabhangig von der Kartenplaniomi. 5 

Abhangig von den in der Teilstruktur geladenen Applikalionen konnen dann niitieis der Karte Transaktionen zwischen 
deni Karteninhaber und Service-Providem, die von den geladenen Applikationen abhangig sind, durchgefiihrt werden. 

Vorzugsweise weist die Chipkarle femer einen Trans fer-Speicherbereich auf, in den die bei der Durchfuhrung von 
Transaklionen auszutauschenden Daten geschrieben bzw. aus deni sie gelesen werden. Indeni lur das Bntnehmen von 
Daten aus deni Transfer-Speicherbereich temiinalspezifische Schlussel vorgesehen werden, sind die einzelnen Zugrirt^ to 
sicherheitstechnisch voneinander unabhangig. 

Die einzelnen in der Karte vorhandenen Teilstrukluren bzw. Applikationen sind vorzugsweise voneinander unabhan- 
gig undjeweils einem bestinimten Service-Provider zugeordnet. Sie stellen sozusagen die fur diesen Service-Provider 
proprietaren oder spezifischen Daten zuni Durchl-uhren einer bestimiiiten Applikation dar. Sie enthaiten deshalb je nach 
Applikationstyp und je nach Service-Provider unterschiedhche Inforniationen, beispielsweise Daten, die einen bestimni- 15 
ten Wert reprasentieren (Bonuspunkte, Kontostand, etc.), Infonnationsdaten uber die Applikation, Informal ionsdaten 
iiber den Service-Provider, etc. Vorzugsweise enthaiten sie jedoch insbesondere auch fur die Applikation spezifische 
Schlussel, mittels derer ein Zugriff auf die Daten der Teilstruktur auf sicherheitstechnisch von anderen Teilstrukluren un- 
abhangige Art und Weise emioglichl wird. Das Laden oder Generieren der Teilslruklur bzw. Applikation selbst isl dage- 
gen mit zumindesl einem ubergeordneten Systemschliissel abgesichert. 20 

Vorzugsweise findet vor dem Durchfuhren einer Transaktion eine gegenseitige Authentifizierung zwischen ('hipkarte 
und einem Terminal statt, wobei dabei ein applikalions- bzw, leilstrukturspezifischer Authentifizierungsschliissel vorge- 
sehen isl. 

Zum Durchfuhren von Transaktionen werden dann Daten in eine fiir die jeweilige VAS-Applikation reservierle Teil- 
struktur geschrieben oder daraus gelesen oder uber den Transfer-Speicherbereich abgewickell. Im ersten Fall werden 25 
appHkationsspezifische Schlussel verwendet. Im letzleren Fall wird ein applikalionsspezifischer und vorzugsweise auch 
cin tcrminalspczifischcr Schlussel, der beispielsweise mittels cincs Schlusscl-Erzcugungsschlusscls, der auf der Karte 
vorgesehen isl und aus applikalionsspezifischen Daten generiert wird, verwendet. Die so in den Transferspeicher ge- 
schriebenen Daten konnen dann vom Service-Provider uber das Terminal entnommen werden, was vorzugsweise durch 
Kennzeichnen der im Transferspeicher gespeicherlen Daten als entwerlet geschiehl. Handelt es sich dabei um einen Ser- 30 
vice-Provider, der nicht fur die schreibende Applikation spezifisch isl, so wird dadurch ein sogenannler Interservice aus- 
gefuhrt, d. h. es werden zum Nutzen bzw. auf Kosten des Karteninhabers geldwerte Daten zwischen unterschiedlichen 
Service-Providern ausgetauschl. 

Als zusalzliche Sicherung isl ferner eine PIN oder ein PaBwort zur Verifikalion der Berechligung eines Transakiions- 
vorgangs vorgesehen. 35 

Durch die variable Struklur der Karte konnen zu verschiedenen Zeitpunkten verschiedene Applikationen in unter- 
schiedlicher Anzahl auf der Karte untergebracht sein. 

Die Echtheil von aus dem Trans fer-Speicher entnommenen Daten wird vorzugsweise unter Verwendung eines Signier- 
schlussels bzw. unter Verwendung einer digitalen Unterschrift oder mindestens eines Schlussels gesichert. Besonders 
vorteilhaft isl es dabei, wenn die entnommenen Daten weiter im Transfer-Speicher verbleiben, jedoch lediglich durch die 40 
Karte als entnommen gekennzeichnet werden. Dadurch konnen auch nach der Transaktion noch Infonnationen uber die 
durchgefuhrte Transaktion erhalten werden. Damil und mit der Absicherung der Entnahme ist auch Einmaligkeit nach- 
weisbar. 

Besonders vorteilhaft ist es femer, wenn die in den Transfer-Speicher geschriebenen Daten mit einem Verfallsdatum 
gekennzeichnet sind, nach dem sie ihren Wert verlieren. Dadurch werden Applikationen reahsierbar, die beispielsweise 45 
die BereitsleUung eines fur einen bestimmlen Zeitrauin gultigen Tickets ennog lichen. 

Mittels eines vorzugsweise vorgesehenen Transaklionszahlers konnen die Transaktionsdaten bzw. die Wertdaten hin- 
sichtlich ihrer zugehorigen Transaktion eindeutig besliinmt und identifizierl werden. 

Die erfindungsgemaBe Chipkarle besteht in einer vorteilhaften Ausfuhrungsform also aus einem hierarchischen Spei- 
cherkonzept^ das auf seinen unterschiedlichen Ebenen mittels verschiedener Schlussel gegen Modifikationen abgesichert 50 
ist, das auf der Ebene der Apphkationen hinsichtlich der in den Speicher geladenen Applikationen variabel ist, wobei 
jede einzelne Applikation durch eigene spezifische Schlussel gegenuber anderen abgesichert und von diesen unabhangig 
isl, und wobei die Gesamtslruktur mittels mindestens eines Systemschlussels und mittels einer die Struklur identifizie- 
renden Kennung gesichert und von der Kartenplattform selbst unabhangig ist. Das Konzepl des Transferspeichers er- 
moglicht den Austausch von Daten sowohl zwischen Karteninhaber und Service-Provider als auch zwischen unter- 55 
schiedhchen Service-Providern selbst. Auch das Lesen und Schreiben in den bzw. aus dem Transferspeicher isl durch 
Schlussel abgesichert, wobei diese ebenfalls karten- und appplikationsspezifisch, zusatzlich jedoch auch noch terminal- 
spezifisch sind. Eine Authentifizierung, die vor jeder Transaktion durchgefiihrt wird, sowie optional eine PIN oder ein 
PaBwort erhohen zusatzlich die Sicherheit der erfindungsgemaBen Chipkarte. 

In den Palentanspriichen 21 bis 30 wird ein Terminal zur Verwendung milder erfindungsgemaRen Chipkarle definiert. 60 
Dieses Terminal dient zum Laden oder Loschen von Apphkationen, zur Durchfiihrung von Transaktionen, zum Ansehen 
von Daten sowie zur Durchfuhrung von weiteren in Verbindung mit den jcweihgen Applikationen und Transaktionen 
stehenden Funktionen. Ein Verfahren zum Durchfuhren von Transaktionen zwischen Karteninhaber und Service-Provi- 
der ist in den Anspruchen 31 bis 33 definierl, das Laden von Daten auf eine erfindungsgemalSe Chipkarte definieren An- 
spruche 34 und 35, und Anspruch 36 definiert ein Gesamtsystem aus Chipkarte und Temiinal. 65 

Nachfolgend wird die vorHegende Erfindung anhand eines bevorzugten Ausfuhrungsbeispiels naher beschrieben, wo- 
bei Bezug auf die beihegenden Zeichnungen genomiuen wird. Dabei zeigen 

Fig. 1 schemalisch die erfindungsgemaBe Chipkarte, 

3 
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Fiy, 2 eine schematische Darslellung des Gesainlsystenis der Koiiiponenlen der Erftndung, 
Fig. 3 den DatenfluB im Gesanil system. 

Fig. 4 die nioglichen Applikaiionsklassen und Opcralionen durch ein Transaktionsniodell in scheniatischer Darslel- 
lung, 

5 Fig. 5 eine scheiiialische Darslellung der Sicherheitsarchilekiiir der erfindungsgernaBen Chipkarle, 
Fig. 6 die Daleistruktur einer allgenieinen Implcnienlierungsklasse des VAS-Conlaincrs, 

Fig, 7 verschicdcne Iniplenientierungsklassen des VAS-Coniainers gemaB einein Ausfiihrungsbeispiel der vorliegen- 
den Erfindung, 

Fig. 8 die Dateislruklur des VAS-Conlainers geinaB eineni Ausluhrungsbeispiel der vorliegenden Hrfindung, 
10 Fig. 9 scheniaiisch die Daieisiruklur der Implenieniierungsklasse DF_PT, 

Fig. 10 schematisch die Daleistruktur der Implenieniierungsklasse DF_AD. 

Bevor die Erfindung naher beschrieben wird, sollen einige, iiii nachfolgenden verwendeten Begriffe definiert werden: 
VAS: Value Added Services 

VAS-Karle: Die VAS-Karle isl eine Chipkarle, mil der an den Value Added Services leiigenommen werden kann. Die 
15 VAS-Karte enthalt neben anderen Anwendungen wie z. B. Zahlungsapplikationen (also eleklronische Geldborse) den 
VAS-Container 

VAS-Container: Der VAS-Container beinhallel Datenslrukluren, ZugrilTsbedingungen, Schlussel und (Erganzungs-) 
Kommandos zum Verwalien von VAS-Applikaiionen und der Bereitstellung der Funktionaliiat der VAS-Applikationen. 
VAS- Applikation: VAS-Applikationen enlhalten VAS-Dalen. Zugriff auf die VAS-Daten wird durch die VAS-Appii- 
20 kation gesteuert. Ein VAS -Provider betreibt im VAS-Container eine oder mehrere VAS-Applikationen. Die Nutzung der 
VAS- Applikation definiert sich aus dem Aufbringen, Lesen und Verarbeiten von VAS-Daten. Eine VAS -Applikation 
kann entweder als Intra- oder Interservice ausgepragt sein. 

VAS-Provider: Der VAS-Provider ist fur seine VAS- Applikation verantwordich, die er nach Rahmenbedingungen des 
System Operators und nach seinen eigenen \brstellungen entwickell und danach iiber den System Operator und die Ter- 
25 minals den Cardholders zur Verwendung bereitstelll. Die VAS-Applikationen sind in den VAS-Container der VAS-Karle 
zu laden, bevor daran leiigenommen werden kann, 

Intrascrvicc: Intrascrvicc ist cine Sortc von VAS-Appli kation, die untcr cxklusivcr Regie des jcweiligcn VAS-Provi- 
ders benutzi wird. Intraservice Applikationen sind geschlossene Applikationen in dem Sinne, daB keine Abrechnung 
oder Lei stung subertragung mit extemen Partnem erfolgl, Eine VAS -Applikation kann entweder als Intra- oder Interser- 
30 vice ausgepragt sein. 

In terser vices: Interservice Applikationen sind Intraservice Applikationen, die uber zusatzliche AuBenbeziehungen zu 
externen Partnem unterhalten. Eine VAS-Applikadon kann entweder als Intra- oder Interservice ausgepragt sein. 

SO, System Operator: Der System Operator, oder System Betreiber, bietel den VAS-Providem und den Cardholders 
das VAS -System zur Nutzung an. 
35 Issuer: Der Issuer, oder Kartenherausgeber, bringt die VAS-Karten mit VAS-Container in den Umlauf. 

CH, Cardholder: Der Cardholder, oder Karteninhaber, ist die Person, die die Karte (hier: VAS-Karte) besitzt und ein- 
setzl, um an den Value Added Services teilzunehmen. Diese Person ist nicht zwangslaufig der eigentliche Eigentiimer der 
Karte. 

Servicetenninal: Das Serviceterminal wird vom System Operator fiir VAS-Applikationen aufgestellt. Am Serviceter- 
40 minal kann der Karteninhaber die VAS-Applikationen auf seiner VAS-Karte verwalten (Laden, Ansehen, Loschen und 
Ubertragen von VAS-Applikationen). 

Handlerterminal: Das Handlertemiinal besitzt Zalilungsfunktionen und bietet zusatzlich VAS-Funktionalitat. An ihm 
setzt der Karteninhaber seine VAS-Karle ein, um einerseils zu bezahlen und gleichzeitig an den Vorteilen von VAS teil- 
zunehmen. 

45 AID: (Application Identifier) maximal 1 6 Byte langer Name von Applikationen zur eindeutigen Unterscheidung von 
Applikationen und der Applikationsselekdon von auBen ohne Kenntnis der Daleistruktur einer Karte. Die AID besteht 
aus einer 5 Byte langen Registered Application Provider ID (RID) und optional aus einer maximal 11 Byte langen Pro- 
prietary Application Identifier Registration (PIX). 
DF: Directory File nach ISO 7816 
50 EF: Elementary File nach ISO 78 1 6 

GUI tiger VAS-Container: VAS-Container, der sich gegeniiber der externen Welt authentisieren kann. 
KID: (Key Identifier) Nunimer eines Schliissels innerhalb eines Elementary Files, das Schlussel enthalt 
R&R: Rules and Regulations 

p: Maximale Zahl von Objekten der Implementierungsklasse DF_PT 
55 a: Maximale Zahl von Ob jekten der Implementierungsklasse DF_AD 

nrpi^: Maximale Gesamtzahl von Objekten: nri^ji^ = p + a. Die Anzahl von Records in EF_DIR ist nr^ju^. 
"''EF TRANSFER' Anzahl von Records des EF_TRANSFER. 

Fig. 1 zeigt schematisch die Strukturder erfindungsgernaBen Chipkarle. Zusatzlich zu den statisch und nicht verander- 
baren, beim HerstellungsprozeB aufgcbrachten Dalen wie dem Masterfile MF und der (optional vorhandenen) Geldbor- 

60 senfunktion DF_Borse ist auf der erfindungsgernaBen Karte noch ein Ver/eichnis bzw. eine Dalenslruklur oder Datei- 
struklur DF_VAS vorgesehen. Diese dient zur Aufnahme von Zusatzfunktionaliialen, sogenannten Value Added Services 
VAS. Aufgrund dieser Zusatzfunktionalitaten, die Applikationen darstellen, die auch noch zu einein spateren Z^ilpunkl, 
also nach der Herstellung der Karte, auf die Karte geladen werden konnen, ist die Karte hinsichtlich ihrer Funktionaliia- 
ten und der mit ihr durchfuhrbaren Transakfionen flexibcl und variabel. Der auf der erfindungsgernaBen Chipkarle vor- 

65 gesehene sogenannte VAS-Container (DF_VAS) emioghcht die Variabifitat und Flexibililat der Chipkarle bezugfich ih- 
rer Funktionen und lost daneben die auf der Chipkarle untergebrachten Applikationen sicherheitslechnisch von der Kar- 
lenplattform, so daB diese von der Karlenplattlbmi unabhangig sind und evenluell sogar auf eine andere Karte ubertragen 
werden konnen. 
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Die erfindungsgeinaBen, neuen Zusatzfunktionalilaten (Value Added Services, VAS) werden realisiert durch Mikro- 
prozessor-Chipkarten. Die Uiiisetzung dieser Zusatzlunktionalitaien wird durcli den VAS-Container realisiert. Der VAS- 
Container auf der Mikroprozessor-Chipkarte biidet die Plattfonn zur Aufnahnie der V'\S-Applikationen. Die VAS-App- 
likationen sind die jeweiligen Realisierungen bestiinniter Zusatzfunktionalitaten. 

Ini Fall der elektronischen Geldborse wird das Bezahlen mil der Karte (Zahhingsfunktion) und die Niitziing einer 5 
VAS-Applikation (Zusatzfunktionalitat) liber getrennte Mechanisinen abgewickell; aus Sicht des Kartennulzers bzw. 
Karteninhabers kann dies aber als ein Vorgang erscheinen. 

Die Mikroprozessor-Chipkarte wird erweilert. uni den VAS-Container, der verschiedene und unabhangige Applikatio- 
nen aut'nehiuen kann. Hr stellt Funktionen zuni Aulbringen, Loschen und tibertragen dieser Applikationen zur VerfU- 
gung; diese konnen nur voiii auiorisierten Systenibetreiber verwendet werden. Der VAS-Conlainer ist daten- und sicher- lo 
heitsiechnisch unabhangig von anderen Systemkoinponenten auf deiii Mikroprozessor-Chip. Der VAS-Container ist 
vollstandig durch sich selbst definiert und allein funktionsfahig. Fur ihn ist eine unabhangige Sicherheitsarchitektur de- 
finiert, so daR VAS-Applikationen eigenstandige Sicherheitsfunktionen verwenden. Die Sicherheitsarchitektur verwen- 
det karlenspezifische Schliissel, die nicht herstellerspezifisch und die unabhangig von Identifikalionsmerknialen der Kar- 
tenplattfomi sind. 

Der VAS-Container verwendet auch Mechanisinen zur Ableitung temiinalspezifischer Schlussel. Mit diesen kann der 
VAS-Container selbst aktiv die Echtheit von Tenninals bzw. die von ihnen erzeugten Daten priifen. 

Ini VAS-Container werden die VAS-Applikationen abgelegt , die uber Mechanisnien des VAS-Container Daten bereit- 
stellen und dadurch die Steuerung der zugeordneten Schnittstellen bewerkstelligen. Der VAS-Container eniiogiicht und 
steuert auch den sicheren Austausch von Daten fiir Interservices zwischen Partnem. Der VAS-Container erledigt aktiv 20 
die KontroUe, d. h. die Echtheit und die Einmaligkeit, der iibertragenen Daten werte. 

Ein Vorteil des VAS-Container gegenuber anderen Ansatzen von Multi-Applikations-Karten ist, daB dieses Konzept 
unabhangig von einer bestimiiiten Kartenplattfomi ist. Es bietet eine Sicherheitsarchitektur, die unabhangig von platt- 
fomispezifischen Sicherheitsmechanismen (wie Schlussel, Identifizierungsdaten, PIN, Signaturverfahren) ist. 

Ein weiterer Vorteil des Konzeptes VAS-Container ist, daB die Anzahl der verschiedenen Applikationen auf der Karte 25 
nicht lest vorgegeben ist durch Beschrankungen und Vorgaben zuin Zeitpunkt der KarLenherstellung oder der Kartenaus- 
gabc; die aktucllc Kartcnbclcgung mit Anwcndungcn ist frci wahlbar durch den Kartcnnutzcr und ist nur durch den auf 
der jeweiligen Karte zur Verfiigung stehenden Speicherplatz beschrankt. Die Anzahl der aktuell auf einer Karte gelade- 
nen VAS-Applikationen hangt vom tatsachlichen Gebrauch der Karte ab. Der Kartennutzer stellt individuell die VAS- 
Applikationen auf seiner Karte zusaiiiinen; dies beinhaltet auch die Anderung der Zusamnienstellung zu einein spateren 30 
Zeitpunkt. Der VAS-Container emioglicht eine multifunktionale Karte, bei der die Kartenfunktionalitat wahrend des Le- 
benszyklus der Karte variabel in Anzahl und Art der Anwendungen zusammengestellt und verwendet werden kann. Es 
konnen so auch Anwendungen, fur die bislang einzelne, spezielle Karten notwendig waren, auf nur einer Karte abgelegt 
werden und zum Einsatz koiiinien. VAS-Applikationen konnen auch auf andere Karten ubertragen werden. Daiiiit kon- 
nen VAS-Applikationen den Lebenszyklus einer Karte uberleben; sie begleiten den Kartennutzer wahrend des Lebens- 35 
zyklus der Anwendungen. 

Die Mikroprozessor-Chipkarte mit Zusatzdiensten ist ein geeignetes Medium zur Verbreitung und zur Vermarktung 
von Dienstleistungen, bei denen auf geschutzte Daten zugegritfen werden muB. Diese Mikroprozessor-Chipkarte kann 
als Zahlungsmittel, Recheneinheit und zur Wertautl^ewahrung verwendet werden. Sie kann entsprechend dem Kunden- 
wunsch vom Kunden selbst und nach Kartenausgabe flexibel mit Zusatzdiensten versehen und zu deren Steuerung her- 40 
angezogen werden. Sie kontrolliert auch aktiv die Auihentizitat von beteiligten Tenninals und stellt die Einmaligkeil und 
Echtheit von ubergebenen Daten sicher. 

Fig. 2 zeigt eine Systemubersicht. Darin dargestellt sind die Systemkomponenten. 

Ein Systembetreiber (System Operator) stellt das System zur Verfiigung. An Servicetemiinals (ST) konnen VAS-App- 
likationen geladen, geloscht und ubertragen werden; weitere Operationen sind: VAS-Applikation auswalilen, ansehen, 45 
interpretieren usw. 

Die Anbieter von VAS-Applikationen, die sogenannten VAS-Provider, entwerfen eigene VAS-Applikationen nach den 
Rahmenbedingungen des Systembetreibers und, soweit moghch, nach eigenen Vorstellungen. Durch AbschluB mit einer 
digitalen Unlerschrift werden die entsprechenden Terminalprogramme auf Echtheit nachpriifbar. 

Fig. 3 zeigt den DatenfluB ini System. 50 
Die VAS-Applikationen werden uber den Systembetreiber an den Terminals den Kartennutzem zur Verwendung be- 
reitgestellt. VAS-Applikationen sind in den VAS-Container der erfindungsgemaBen Chipkarte zu laden, bevor daran teil- 
genoinmen werden kann. 

An Handlertenninals (HT) wegen auf der Karte vorhandene VAS-AppUkadonen genutzt, indem VAS-Daten aufge- 
bracht bzw. geloscht werden. 55 

Zur Reahsierung der Mikroprozessor-Chipkarte mil VAS-Funktionalitat wird neben anderen bestehenden Anwendun- 
gen (z. B. Zahlungsapplikationen wie die eleku-onische Geldborse) der VAS-Container auf der Karte aufgebracht. 

Der VAS-Container verwendet Funktionen, die ein Aufbringen, Loschen und Ubenragen von VAS-Applikationen er- 
moglichen. Diese Verwaltungsfunktionen werden ausschlieBlich vom System Operator benutzt und sind in der Karte ge- 
gen Frenidhenutzung abgesichert. Der VAS-Container beinhaltet einen Transferspeicher, niit deni der Austausch von Da- 60 
ten zwischen VAS-Applikationen realisiert wird. 

Zur Steuerung des Transferspeichers werden zwei Kommandos TRANSFER und TAKE eingesetzt. Das Kommando 
TRANSFER erzeugt einen Eintrag im Transferspeicher mit fiir die jeweihge Applikation spezifischen Daten. Neben den 
Nutzdaten zahlen hierzu auch die zur Steuerung der Verarbeitung notwendigen Angaben wie Datum, Verfallsdatum und 
Idendfikanonsdaten. Mit dem Kommando TAKE werden Objekte aus dem Transferspeicher entnoramen und als entnoiu- 65 
men markiert. Je nach Anwendungsfall werden die Objekte dann als weiterhin gultig oder als ungiiltig markiert. Uber- 
tragene Daten werden durch den VAS-Container auf Echtheit und Einmaligkeit uberpriift. 

VAS-Applikadonen verwenden zur Bereitstellung undSteuerung der Anwendungen VAS-Daten. Zugriff auf die VAS- 
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Daten wird durch die VAS-Applikation geslcuerl, die sich dazu Mechanisnien bedienU welche im VAS-Con!ainer alien 
Applikaiionen berciigeslelli sind. Ein VAS-Provider belreibt iin VAS-Coniainer eine oder ntehrere VAS-Applikaiionen. 
Die Nulzung der VAS-Applikalion definiert sich aus dem Aufbringen, I-Xsen und Verarbeiten von VAS-Dalcn. 

Der VAS-Container unterslulzt Interservices. Inlerservices erfordem ZugrilT auf genieinsame Dalen, Ubertragung von 
5 Leistungsanspriichen und die Abrechnung von Leistiingen zwischen verschiedenen Partnem. 

IiTi Iblgenden sollen die mil der erfindungsgeniaBen Chipkarle nioglichcn Diensle bzw. Applikaiionen anhand von 
Bcispielen aufgezeigl werden. 

Die Beschreibung beziehl sich jeweils auf die Erscheinungsweise und Funklion nach deni Siand der Technik. Die 
Funkrion soil zukuntiig durch eine oder mehrere VAS-Applikalionen nachgebildet werden. 
10 Als ersies werden Inlraservices vorgestelll. 

Bei spiel A: Kundenclub 

Ein KaulTiaus betreibt einen Kundenclub. Der Kunde wird in diesein Club Mitglied und erhall mit diesem Status spe- 
15 zifische Clubleistungen, die Nichtmitglieder nicht erhalten konnen. Heule identifiziert sich ein Clubmitglied in der Club- 
unigebung durch einen Clubausweis. Der Clubausweis wird beim EintriUerstellt, ist nicht ubertragbar, und hat in der Re- 
gel eine Gultigkeitsdauer. Uber den Clubausweis werden keine spezifischen Transaktionen abgewickelt, d. h. es besteht 
keine Kopplung mit dem Kundenutnsatz. Damit grenzt sich der Clubausweis von Bonusprogrammen ab, in denen ein 
Zusainiiienhang Status/Umsatz besteht. 
20 Analog: GroBhandler Ausweis, Senator Card, Buchclub. 

Ziel: Die (^lubzugehorigkeit soli durch eine Applikation im VAS-C^ontainer nachgewiesen werden. 

Bei spiel B: Bonus system 

25 Ein Kunde erhalt fiir jede Transaktion einen Bonusanspruch vergutet. Der B on usan sprue h wird kumuliert und kann an 
eineiii durch den Kunden definierlen Zeilpunkt lur eine geldwerte Leistung eingetauscht werden. Der Bonusanspruch gilt 
fiir cincn dcfinicrtcn Zcitraum und kann anonym oder pcrsoncnbczogcn vcrwaltct werden. Der Bonusanspruch cntstcht 
durch Umsatz oder Nutzungshaufigkeit. 
Analog: Punktestand von Miles & More. 

30 Ziel: Das Punktekonto soil durch eine AppUkation im VAS-Container verwaltet werden. 

Beispiel C: Rabatt 

Der Kunde erhalt Volunienrabatt nach Plan. Der Rabatt wird fur jede einzelne Transaktion gewahrt. Die Karte verwal- 
35 tet keine Umsatzhistorie. Jede Transaktion ist in sich abgeschlossen. 

Ziel: Der Rabattanspruch soli durch eine VAS-Applikation ausgewiesen werden. 

Beispiel D: Ausweisfunktion 

40 Eine Person kann durch Merkmale in der Karte gegeniiber Dritten nachweisen, daB Berechtigung zu bestiminten Lei- 
stungen besteht. Die Zugehorigkeit der Person zum Ausweis muB bei jeder Transaktion nachgewiesen werden (Lichtbild, 
PIN, Biometrik). Die Echtheit des Ausweises wird als Sicherheitsnierknial herangezogen. 

Analog: Internet Zugang, Zugang Homebanking, Telefonkarte. 

Ziel: Die Berechtigung soil durch eine VAS-Apphkation nachgewiesen werden. 

45 

Beispiel E: Werteinheiten 

Werteinheiten werden erworben und durch ein- oder iiiehrmalige Nutzung verbraucht. Pro Transaktion verringert sich 
der Wert um eine oder mehrere Einheiten. Die Nutzungsberechtigung ist ubertragbar und kann Einschrankungen fur die 
50 Nutzung beinhalten. 

Analog: Einzelfahrschein, Streifenfahrschein, Abo-Konzertkarte, Squash-&hnerkarte, Kino-Ticket, Telefoneinhei- 
ten. 

Ziel: Durch eine VAS-AppHkation soil die Abwicklung ralionahsiert werden. 
55 Beispiel F: Nutzungsabrechnung 

Die Nutzung einer Leistung wird nach Zeit, Haufigkeitoder Menge registriert und nach Tarifplan abgerechnet. Im vor- 
aus ist nicht bekannt, in welchem Unifang die Leistung abgerufen wird. 

Analog: Verzehrbon, Kurzzeitparkschein. 
60 Ziel: Durch eine VAS-Applikation soil die Abrechnung nach Tarif ennoglicht werden. Die jeweils aktuell benotigten 
Abrechnungsdaten sollen ini VAS-Container gespeichert sein. 

Beispiel G: Merkzettel (Mobiler Datenspeicher) 

65 Diese Applikation ermoglicht die Ubergabc von Daten des Karteninhabers an den VAS-Provider. Dadurch werden Ab- 
laufe automatisiert, die derzeit noch manuell erfolgen. Aus diesen Daten laBt sich kein geldwerter Gegenwerl ableiten. 
Analog: AusfuUen von Lottoscheinen, Einkaufszetiel, Kassenzettel, Telefonregister. 

Ziel: Ein VAS-Provider soil die Daten der Karte entnehmen und so den entsprechendcn Dienst direkt erbringen konnen 
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(z. B. Teiefonverbindung hersietlen, gewunschle Waren zusamiiienstellen, elektronisch den Lotloschein ausfullen und 
erfassen). Die Daten konnen sowohl kurzfrislig als audi langfristig in der Kane gespeicheri werden. 
Nach diesen Beispielen fur Intraservices sollen nun einige Beispiele fiir Interservices foigen. 

Ein In terser vice enlsteht imnier dann, wenn an eineni Dienst mehrere VAS-Provider beleiligt sind. Dies ist untrennbar 
damil verbunden, daB Dalen den Bereich eines VAS-Provider verlassen. Heute geschieht dies iiber Bescheinigiingen auf 5 
Papier. 

Beispiel A: Fahrpreisers t at lung 

Ein Kaufhaus erslallet eineni Kunden den Fahrschein eines OPNV-Uniemehniens fur die Fahrt zuni Kaufhaus. Der lo 
Kundc muB dem Kaufhaus den Einzelfatirschein vorlegen. Das Kaufliaus vcrnierkt auf deni Fahrschein, daB er erstattet 
wurde. Eventuell bekomml das Kaufhaus seinerseits einen Teil der Erstaitung an den Kunden voni Verkehrsunternehnien 
/.uruck. 

Ziel: Der Erstattungsvorgang soil elektronisch abgewickelt werden. 

15 

Beispiel B: Fahrgutschein 

Ein Kaufhaus erstattet dem Kunden beini Warenkauf die Kosten fur eine Heimfahrt, indeni ein Gutschein ausgestellt 
wird. Der Kunde erhalt an eineni Fahrkartenschalter ein Ticket des OPNV bzw. zahlt einen geringeren Preis fiir das Tik- 
kei. Der Verkehrsbetrieb rechnet den Gutschein mil dem Kaufliaus ab. 20 

Ziel: Abbildung der Mechanisnien durch VAS-AppHkadonen mit eiektxonischer Abrechnung zwischen Handel und 
OPNV. 

Beispiel C: Kundenparkplatz 

25 

Ein Kaufhaus erslattet dem Kunden einen Teil der Parkgebiihren bei Benutzung eines bestimmten Parkhauses. Das 
Parkhaus wird durch ein unabhangigcs Untcrnchmcn bclricbcn und crhalt vom Kaufliaus cine geldwcrtc Vcrgiitung fiir 
jede Kundengutschrift. 

Ziel: Abbildung der Mechanisnien durch VAS-Applikationen mit. elektronischer Abrechnung zwischen Handel und 
Parkhaus. 30 

Beispiel D: Multilaterales Bonusprogramm 

Eine Gruppe von Handelsunternehmen und Dienstleistern einigt sich auf ein genieinsanies Bonusprogramm. 
Ziel: Jeder Partner kann Bonuspunkte auf einem genieinsamen Konto auf der Karte gutschreiben oder vetguten. Die 35 
Abrechnung der Leistungen zwischen den Partnem erfolgt durch das Hintergrundsystem. 

Beispiel E: Anerkennung von Bonuspunkten zwischen Dienstleistern 

Jeder Dienstleister betreibt ein eigenes Bonusprogramm, hat aber Absprachen mit anderen, gesammeite Punkte anzu- 40 
erkennen. Bekannte Beispiele sind Absprachen zwischen Autovermietem und Ruggesellschaften zum Samnieln von 
"Meilen". 

Ziel: Unterstiitzung der Ubertragung von Bonuspunkten durch die Karte. 

Jeder VAS-Provider soli zunachst seine Punkte fiir sich sammeln, ohne daB ein anderer eingreifen kann. Fiir die Uber- 
tragung sollen sichere Mechanisnien bereitgestellt werden. 45 

Beispiel F: Nachttaxi 

Durch einen Fahrausweis des OPNV wird gleichzeitig die Berechtigung zur Fahrt im Sammeltaxi (z. B. nach 22.00 
Uhr) erworben. Das Taxiuntemehmen muB zur Abrechnung nachw^eisen, daB der Falirausweis voigelegen hat. Die Inan- 50 
spruchnahme des Taxis wird auf der Karte veniierkt, um MiBbrauch zu unterbinden. 

Ziel: Die VAS-Apphkation soil die Inanspnichnahme, KontroUe und Verrechnung dieses Dienstes ermoglichen. 

Im folgenden soil der Aufbau der crfindungsgeniaBen Chipkarte naher beschrieben werden. 

Die Mikroprozessor-Chipkarte mit VAS-Funktionaiitat enthalt insbesondere den VAS-Container. 

Der VAS-Container ist eine eigenstandige Anwendung und existiert entweder alleine oder auch parallel neben anderen 55 
Applikationen auf der zugrundehegenden Kartenplattform. Der VAS-Container ist vollst andig durch sich selbst deiiniert 
und allein funklionsfahig. Er kann ohne die in der Kegel auf der gleichen Karte vorhandene Zahlungsfunklion betrieben 
werden. Insbesondere wird fiir den VAS-Container eine unabhangige Sicherheitsarchitektur definiert, so daB VAS-App- 
likationen eigenstandige Sicherheitsfunktionen verwenden konnen. 

Teil der Value Added Services sind Transaklionen durch den Kunden, die an Terminals der VAS-Provider durchge- fio 
fiihrt werden. Der VAS-Provider hat ein Interesse, diese Transaklionen zu verfolgen, sei es zum Zweck der Systemiiber- 
wachung oder sei es zur Sammlung von statistischen und anderen Daten. Zur Optimierung und Vereinheitlichung der Da- 
tenstrukturen in der Karte wird von der Vcrwendung appHkationsspezifischer Identifikationen abgeraten und dieNutzung 
einer systemweit eindeutigen VAS-Container ID empfohlen. Diese Nummer kann vom VAS-Provider zur Realisierung 
der o.g. Funktionen benutzt werden, und sie befreit ihn von der Burde, eigene Nummemkreise zu verwalten. 65 

Die Sicherheitsarchitektur des VAS-Containers verwendet diese systemweit eindeutige ID zur Ableitung kartenspezi- 
fischer Schliissel. Die Verwendung der kartenspezifischen Nunuiier ware im Prinzip moglich, wird aber vorzugsweise 
nicht verwendeu da, falls der VAS-('ontainer auf unterschiedHchen Platifoniien implementiert wird, diese unter Umstan- 
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den kollidierende Numniemkreise verwenden. 

Die VAS -Container ID wird vom System Operator vergeben und durch den Kartenissuer bei der Erzeugung des VAS- 
Containers eingebracht. Sie wird mil deiTi I^schen dcs VAS -Containers vemichlei und daniit aus deni System entfemt. 
Ein VAS-Container gilt als geloscht, wenn er keine VAS-Applikationen enlhalt und die VAS-Container ID entfemt ist. 
5 Bei einer Gesamtiibertragung des VAS-Containers von einer alten in eine neue Karte wird die VAS-Container ID zu- 
samnien niit den VAS-Applikationen iransferiert. Dieser Transler entspricht einem Verschieben des VAS-Containers aus 
der alien in die neue Karte. Die aire Karte enthalt nach diesein Vorgang keinen VAS-Container inehr. Der in der neuen 
Karte vorhandene VAS-Container wird bei dieser Operation iiberschrieben und daniit geloscht. Da die VAS-Container ID 
von der alten aut die neue Karte ubertragen wird, ist in den Hintergrundsyslenien der VAS-Provider keine Uniwandlung 
m der Bezugsnuniniem erforderlich, 

Einzelne VAS-Applikationen konnen nur unter der Kontrolle des jeweiligen VAS-Providers zwischen zwei verschie- 
denen VAS-Containem verschoben werden. Bei dieser Funktion andert sich die Zuordnung zwischen VAS-Container ID 
und VAS-Applikation, was u. U. im Hintergrundsystem des VAS-Providers vennerkt werden niuR. 

Der VAS-Container enthalt keine personenbezogenen Merkmale. VAS-Applikationen konnen personenbezogene Da- 
15 ten enthalten, der Umfang soUte jedoch aus Datenschutzgrunden und zur besseren Speicherausnutzung aul^ ein Minimum 
beschrankt werden. VAS-Applikationen sollen, falls erforderlich, personenbezogene Daten im Hintergrundsystem spei- 
chem und die Zuordnung zur Karte iiber die VAS-Container ID herstellen. 

Ein wesentliches Merkmal des VAS-Containers ist die Unterstutzung von In terser vices, Interservices erfordern Zugriff 
auf gemeinsame Daten, Ubertragung von Leistungsanspruchen und die Abrechnung von Leislungen zwischen verschie- 
20 denen Partnem. Der VAS-Container muB dieses ennoglichen und trotzdem die Sicherlieit der Applikationen ini Intraser- 
vice gewahrleisten. 

Sogenannte Intraservice VAS-Applikationen sind Apphkationen, die unter der exklusiven Kontrolle des VAS-Provi- 
ders betrieben werden. Der VAS-Provider definiert die Sicherheit seiner Applikation unabhangig von einer externen 
S telle. Ohne Weitergabe der Schlussel kann keine exierne Partei VAS -Daten verandem. 

25 Zur effizienten Abwicklung von Interservices mussen die Partner auf gemeinsame Daten zugreifen konnen. Der ge- 
meinsame Zugriff auf die Daten isl iiber abgestufte Sicherheitsniechanisnien realisieru 

Die crste Stufc dcs gcmcinsamcn Zugriff s crfolgt ausschlicBlich iiber offcnllichc Transfcrfcldcr VAS-Provider konnen 
uber diese Felder Daten austauschen, ohne gegenseitig die Applikationen und Schlussel kennen zu mussen. Lediglich 
zum Schreiben von Daten in die Transferfelder iniissen die Terminals iiber geeignete Schlussel verfugen, nicht aber zum 

30 Lesen. Lesen darf jeder ohne Einschrankung. Der Datenaustausch kann in beiden Richtungen zwischen VAS-Provider 
und Partner erfolgen, wenn jeder iiber seinen Schlussel zum Schreiben verfugt. Die Transferdaten konnen aus einer In- 
traservice VAS- Applikation des VAS-Provider erzeugt werden oder umgekehrt kann der VAS-Provider Daten aus dem 
Transferfeld in seine Intraservice VAS -Applikation hereinnehmen. 

Die zweite Stufe ist das Entwerten von Werteinheiten, die durch VAS-Daten verkorpert werden. Ein VAS-Provider 

35 bringt Werteinheiten in die VAS-Daten mit einem speziellen Schliissel zum Schreiben ein. Die Werteinheiten konnen 
durch Interservice Partner abgenutzt werden, die iiber einen Schliissel zum Entwerten verfijgen, den sie voni gesamtver- 
antwortlichen VAS-Provider bekommen. In dieser Stufe greifen Partner mit unterschiedhchen Rechten auf nicht-offent- 
liche VAS-Daten zu. 

Die dritte Stufe ist der direkte schreibende Zugriff auf die VAS-Daten durch alle beteiligten Interservice Partner. Diese 
40 Melhode erfordert ein entsprechendes MaB an Vertrauen zwischen den Parteien, da uneingeschrankt VAS-Daten veran- 
dert werden konnen. 

Das Transferfeld dient als Koppelghed zwischen VAS-Applikationen. Daten im Transferfeld werden von den VAS- 
Applikationen im VAS-Container erzeugt. Daten konnen auch direkt im Transferfeld angelegt werden, wenn der Erzeu- 
ger keine eigene VAS- Applikation im VAS-Container betreibt. 
45 Das Transferfeld steht prinzipiell alien Applikationen zur Verfiigung, schreiben darf aber nur wer iiber eine Berechti- 
gung (Schlussel) dafiir verfiigt. Nur nach den Regeln, d. h. den Rules und Regulations R&R, dazu berechtigte Empfanger 
durfen Daten aus dem Transferfeld entnehinen. Der Empfanger priift das Vorhandensein von fur ihn bestinimten Trans- 
ferdaten und entnimmt sie zur Verarbeitung im eigenen System. 

Um die Manipulation von Transferdaten im offentlichen Austausch zu verhindem, bringt der Erzeuger ein Echtheits- 
50 merkmal und der VAS-Container eine Sequenznunimer ein. Mit diesen Elenienten wird die Einmaligkeit einer Transfer- 
nachricht sichergestellt und der Ursprung der Daten nachgewiesen. 

Bei Bedarf wird der Empfanger der Transferdaten vom Er/euger mit der Moglichkeit ausgeriistet, eine Echtheitsprii- 
fung durchzufiihren. Wird dies nicht gewunscht, kann die Akzeptanz der Daten auch nach Treu und Glauben erfolgen; 
das Echtheitsmerkmal wird dann u. U. erst bei einer Abrechnung im Hintergrundsystem des erzeugenden VAS-Provider 
55 gepriift. 

Die Daten konnen aus dem Transferfeld nur einnialig mit Erhalt eines Echtheitsmerkinals entnonimen werden. Bei der 
Entnahme werden die Daten markiert und verbleiben (als Kopie) itn Transl-erfeld. Damit kann auch nach der Entnahine 
der Daten fur einen bestimmten 2^itraum der Transfer vorgang nachgewiesen werden. 

Daten im Transferfeld tragen ein Verfallsdatum. Verfallene Daten konnen bei Bedarf von beliebigen Applikationen 
60 iiberschrieben werden. Die Daten im Transferfeld konnen bei der Entnahme markiert werden, so daR sie zum sol'ortigen 
Uberschreiben freigegeben sind. Sollte sich der Transferspeicher dennoch volistiindig fiillen, bevor ein Transferdatensatz 
verfaUt, so niu6 der Karteninhaber am Servicetenninal nicht mehr benotigte Eintrage loschen. 

Fur die Modellierung von VAS-AppHkationen werden 3 Operationen definiert. Diese Operationen wirken auf die 
VAS-Daten. Laden und Loschen von Applikationen sind Funktionen des VAS-Containers und werden in den folgenden 
65 Absatzen nicht betrachtet. 

Erwerben Allgemein das Erwcrben eines Leistungsanspruchs und die Ablage eines Nachweises in den VAS-Daten ei- 
ner VAS-Appiikation. 

Entwerten Allgemein das Einlosen des Anspruchs ohne, mil vollstandigem oder mit leilweisem Verbrauch von VAS- 
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Daten einer Applikation. Der Vorgang erzeugt eine elektronischc Quiiiung, die ini Transferfeld abgelegi wird. Diese 
Quiuung tragi ein sin n voiles Verfallsdaiuiiu zu deni sie aus deni Transferspeicher gcloschi werden kann. 

Entnehnien Allgeinein die Entnahiiie der elektronischen Quittung aus eineni Transferfeld zur weileren Verarbeitung 
(z. B. Hintergrundsysieni). Eine Kopie der Quittung verbleibt und dient als Nachweis des "Entwertens". 

"Erwerben" von VAS-Daten kann nurdiirch den jeweiligen VAS-Provider erfolgen. "Entwerten" von VAS-Daten kann 
nur durch den VAS-Provider erfolgen, der sie tiiit "Erwerben" erzeugle oder durch einen Interservice Partner, den der 
VAS-Provider dazu emiachligt. "Entnehnien" kann auch durch jeden anderen VAS-Provider erfolgen. Bei einein Inter- 
service ohne gleichberechtigten Zugriff auf die VAS-Daten lost der Partner den Zustandsiibergang "Entnehnien" aus. Die 
so gewonnene elektronische Quittung kann dann uber den Systein Operator und das Hintergrundsystem des VAS-Provi- 
der abgerechnei werden. "Erwerben" und "Enlwerten" kann in eineni Schriti erfolgen. 

VAS-Applikationen niit genieinsanien Merkmalen lassen sich in Klassen unterteilen, Diese Klassen bilden die Basis 
fur Datenstrukturen ini VAS-Container. Der VAS-Provider wahlt bei der Iniplementation seiner Anwendung eine Appli- 
kationsklasse aus. 

Es werden dabei folgende Applikalionsklassen definiert: 

- Punktespeicher 

- Ticket 

- Ausweis 

- Gutschein 

- Datenspeicher. 

Punktespeicher bezeichnet eine Applikationsklasse, in der ein Konto von Punktwerten verwaltel wird. Auf das Punk- 
tekonto konnen Werte aufgebucht und abgezogen werden. Das Aufsuchen von Werten erfolgt durch den VAS-Provider, 
indem der Speicher mil deni neuen Kontostand beschrieben wird. Das Abbuchen von Werten erfolgt durch die "Entwer- 
ten" -Operation, wobei als Beleg eine elektronische Quittung im Transferspeicher abgelegt wird. Der Zugriff auf die bei- 
den Funktionen ist durch zwei unterschiedliche ZugrilTsschlussel realisiert. 

Ticket bezeichnet cine Applikationsklasse, in der ein Wcrtfcld cxisticrt, welches cinmalig odcr mchnnalig cntwerlct 
und dainit verbraucht wird. Das Aufbuchen von Werten in der Applikationsklasse Ticket erfolgt einmalig. 

Ausweis bezeichnet eine Applikationsklasse, bei der die VAS-Daten den Nachweis einer Berechtigung beinhalten. 
Der Nachweis wird in der Regel nicht durch Nutzung verbraucht; er wird allerdings nach eineni definierten Kriterium, 
z. B. nach zeithcheni Verfall, ungiiltig. Je nach Auspragung der AppHkation wird die Echtheit des Ausweises (z. B. An- 
wohnerparkschein) oder die Vorlage eines Ausweises dokumendert (z. B. Sainmeltaxifahrt init Monatsfahrschein: Er- 
zeugen einer elektronischen Quittung durch die Karte. Die Quittung wird vom Taxiuntemehinen beim OPNV eingereicht 
und anteilig verrechnet). Optional kann die Nutzung des Ausweises durch elektronische Quittungen im Transferspeicher 
der Karte dokumentiert werden. 

Gutschein bezeichnet eine Applikationsklasse, bei der Leistungsanspruche (in der Regel kurzfristig) in der Karte zwi- 
schengespeichert werden. Diese elektronischen Gutscheine werden ausschlieBlich im Transferspeicher des VAS-Contai- 
ners gespeichert. Die den Gutschein verwertende Applikadon ist in der Regel eine andere als die erzeugende Anwen- 
dung. Die Entnahme des Gutscheins aus dem Transferspeicher ist nur einmalig moglich und wird durch die Karte doku- 
mentiert. Ein vom VAS-Container erzeugtes Echtheitsmerkmal kann bei der Abrechnung im Hintergrundsysieni benutzt 
werden, 

Datenspeicher bezeichnet eine Applikadonsklasse, bei der ein VAS-Provider Daten im VAS-Container speichert, die 
fiir den Kunden einen zusiitzlichen Service bieten (z. B. Letztes Menii in Fast- Food Restaurant, Letzte Lottozahlen, Ser- 
vice Praferenzen, Vorschlagslisten). Die Daten sind nur zur Infomiation und stellen keinen Leistungsanspruch gegen den 
VAS-Provider dar, Der Zugriff auf die Daten wird vom VAS-Provider gesteuert. 

Jede Applikadonsklasse zeichnel sich durch einen typischen Nutzungszyklus aus. Die folgende Tabelle zeigt, in wel- 
cherFrequenz die drei oben definierten Operadonen auf die VAS-Daten der Applikationsklasse angewendet werden (Zur 
Beachtung: "Erwerben" bedeutet nicht "Applikation laden" und "Entnehmen" bedeutet nicht "Applikation loschen"). 
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Tabelle 1 
Nutzungszyklus 

5 





Punkte- 
speicher 


Ticket 


Ausweis 


Gutschein 


Daten- 
speicher 


Erwerben 


Mehrfach 


Einfach 


Einfach 


Einfach 


Mehrfach *** 


Entwerten 


Mehrfach 


Mehrfach 


Mehrfach 


Einfach 


Nie 


Entnehmen 


Mehrfach 


Mehrfach 


Mehrfach 


Einfach 


Nie 



*** In der Applikationsklasse „Datenspeicher'' wird nicht ein Anspruch erworben, 
sondem die Applikation tragt lediglich Daten in die Applikation ein. 

20 

Fig. 4 veranschaulichi die oben aufgeliihrten Applikationsklassen und Operationen durch ein Transaktionsmodell. 
Ini foigenden soli auf die Sicherheitsarchitektur der erfindungsgemaBen Chipkarte naher eingegangen werden. Zur 
Gewahrlei stung der Sicherheil werden die foigenden Schlussel definiert: 

25 Tabelle 2 

Schliissclubcrsicht 



30 


Name 


Ort 


Inhaber 


Beschreibung 




Kso 


VAS- 
Container 


System 
Operator 


SchlQssei fur Verwaltung des VAS- 
Containers 


35 


Kaut 


VAS- 
Container 


System 
Operator 


Schlussel fur Authentifizierung des VAS- 
Containers 




KsiG VASC 


VAS- 
Container 


System 
Operator 


Schlussel zum Signieren der 
Transaktionsdaten 


40 


KGKdec 


VAS- 
Container 


System 
Operator 


Schlussel fur die Ableitung des 

KGKDEc.pix 




Klvasp 


VAS- 

Applikation 


VAS-Provider 


Schlussel fur den Schreibzugriff auf VAS- 
Daten 


45 


Krvasp 


VAS- 

Applikation 


VAS-Provider 


Schlussel fur den Lesezugriff auf VAS- 
Daten 




KGKdecpix 


VAS- 
Provider 


VAS-Provider 


SchlQssei fur die Ableitung des Kqec 


50 


Kdec 


Handler- 
terminal 


VAS-Provider 


Schlussel flir Authentifizierung des 
Handlerterminals 



Die Sicherheitsarchitektur basiert aul dein Lebenszyklus von VAS-Container bzw. VAS-Apphkationen und isi nach 
55 der Verant wortlichkeil der beteiligien Instanzen geschichtet . Eine erlauterende scheniatische Darsteilung ist in Fig. 5 ge- 
zeigt. 

Nachfolgend einige Erlauterungen zur Siruktur des VAS -Containers sowie der darauf aufgebrachten Applikalionen. 

Der VAS-Container sowie VAS-spezifische Erganzungskommandos werden entweder vom Issuer zusammen niit an- 
deren Nicht- VAS- Applikationen auf die Karte gebracht oder spatestens an eineni Serviceterniinal durch einen autorisier- 
60 ten VAS-Provider auf einer beslehenden Kartenplatttbnn integrien,. 

Fur die zweite Moglichkeit kann der folgende Mechanisnius Verwendung finden: Der System Operator verabredet niit 
dem Issuer einen teniporaren Schlussel K^o*- Der Issuer offnet die Karte niit seineiii nur ihni bekannten Schlussel, legt 
die Dateien des VAS-Container an und schreibtinsbesondere den KgQ* in das DF_VAS. Der System Operator kann dann 
zu eineni spateren Zeitpunkt (z, B. die Karte kommt zuni ersten Mai mit einem Servicetenninal in Beruhrung) den 
65 Schlussel Kgo* durch seinen eigenen Schlussel K^q erseizen, den dann nur er alleine kennt. Der System Operator kann 
nun weilerc Daten, wie z. B. den KGK^gj-, selbst eintragen oder im Falle einer Platlfonn mit dynamischer Speicherver- 
waltung Dateien fur VAS- Applikalionen selbst erzeugen bzw. loschen. Daniit ist sichergestellt, daB der Issuer nach der 
ersten Benutzung einer VAS-Karte keinen Zugriff mehr auf den VAS-( Container hal und der System Operator lediglich 
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Zugriff sauf den VAS- Container. Da es mil anderen Applikationen keine genieinsanien Datenslrukluren und keinerlei 
Daienaustausch gibu isl die Sicherheilsarchitektur des VAS-Containers soiiii! unabhangig von anderen auf der Karten- 
plaUfomi vorhandenen Applikationen. 

In einer speziellen Ausfuhrungsfonn der Erfindung soil jedoch von derersten Moglichkeit Gebrauch gemacht werden: 
Der Issner soli ini Aullrag des System Operator den VAS-Container inkliisive aller Schliissel auf die VAS-Karten auf- S 
bringen. 

Der VAS-Container besteht aus einer vorgegebenen Dateistruklur, vorgegebenen Zugrifl^sbedingungen (ACs) und ei- 
nigen globalen Daten. Die globalen Daten enthallen u. a. den Schlussel K^q zuin Laden bzw. Loschen von VAS- Appli- 
kationen. Ober diesen Schliissel, den nurder System Operator kennt, wird sichergestellt, dal.-i nur zugelassene VAS- App- 
likationen geladen werden konnen. Die Karie veriangl dazu eine exteme Aulhentifizierung des System Operators mil lo 

Wenn ein Karleninhaber an eineni Servicetemiinal eine VAS-Applikation laden niochte, beauftragt der zustandige 
VAS-Provider den System Operator damit, dies fiir ihn zu tun. Beim Laden der VAS-Applikation in den VAS-Container 
ubergibt der VAS-Provider dem System Operator die Schlussel Klvasp ^rvasp dieser mil in die Applikation 
eintragt, Durch den Schlussel Klvasp der VAS-Provider Daten der Applikation vor schreibendem Zugriff und zu- 15 
satzHch interne Daten vor lesendem Zugriff schutzen, Dazu verlangt die Karte eine externe Authentifizierung des VAS- 
Provider basierend auf K^vASP*^ ^- ^' Karte pruft aktiv die Echtheit des Tenninals. Nach erfolgreicher Ausfuhrung 
dieser Funktion wird einem Temiinal der schreibende Zugriff^ auf eine VAS-Applikation und der lesende Zugriff auf in- 
terne VAS-Daten der Applikation erlaubt. Eine interne Authentifizierung, d. h. die Priifung der VAS-Applikation (und 
damit der Karte) auf Echtheit durch das Handlerterminal, kann optional erfolgen. Bei der Nutzung der VAS-Applikation 20 
durch den Karteninhaber konnen an beliebigen Tenninals, die iiber den Schlussel Klvasp verfugen, diese intemen VAS- 
Daten in die Applikation geschrieben bzw. verandert werden. Die Funktion "Erwerben" stutzt sich deshalb auf einen UP- 
DATE RECORD Befehl, dem eine externe Authentifizierung mil dem Schlussel Klvasp vorausgehen muB. 

Der lesende Zugriff auf alle nicht intemen Daten der VAS-Applikation ist nur erlaubt, wenn eine vorherige exteme 
Authentifizierung durch K^vasp ^^^^ durch K^q oder durch die korrekte Eingabe einer PIN oder eines PaBwortes durch 25 
den System Operator erfolgt. Der PIN-/PaBwort-geschutzle ZugrilT wird vorgesehen, um Daten fur den Km-teninhaber an 
Tenninals oder am Wallet cinschbar zu machcn. Der Karteninhaber hat an einem Scrvicctcmiinal die Wahl, fur alle App- 
likationen gleichzeitig einen PIN- /PaB wort- Schutz fiir das Lesen der Wert- bzw. Statusdaten zu aktivieren bzw. zu deak- 
tivieren. 

Zu den globalen Daten des VAS-Container gehort ein Schlussel Ks]g_vasc ^um Signieren von eninommenen Daten 30 
aus dem Transferfeld. Anhand der Signatur kann die Unversehrtheit dieser Transakdonsdaten nachgepriift werden, wenn 
sie manipulationsgesichert: zwischen Interservice Partnern zur gegenseidgen Verrechnung ubertragen werden miissen. 
Zusatzlich zu einer optional durch die Interservice Partner eingebrachten Signatur wird fur Datensatze, die die Karte mil 
der Operation "Entnehmen'* ausgibt, eine Signatur basierend auf K^jq vasc einem vom VAS-Container verwalteten 
Transaktionszahler hinzugefiigl. Da zwar Lesen des Transferfeldes jedem erlaubt ist, jedoch die Signatur der Karte mil 35 
KsiG vasc ""^ beim Aufmf der Operation "Enlnehmen" erzeugt wird (und dies kann nur einmalig geschehen), wird die 
unzulassige doppelte Abrechnung von Gutscheinen erkannt. Jeder Interservice Partner kann sich vom System Operator 
die Echtheit und Einmaligkelt eines entnommenen Gutscheins bestatigen lassen. AuBerdem kann vom System Operator 
durch Priifung der Signatur die Echtheit des VAS-Containers nachgewiesen werden. 

SoUte eine Kartenplattfomi asymmetrische Schliissel verfahren unterstiitzen, kann als K^jq vasc ^uch ein privater 40 
(geheimer) Schlussel innerhalb der Kane zum Signieren herangezogen oder ein solcher Schliissel aus einem privaten 
Key Generating Key abgeleitet werden. Die VAS-Provider konnten in diesem Fall oftentliche (nicht geheime) Schlussel 
zur eigenen Priifung der Signatur heranziehen, ohne den System Operator konsultieren zu mussen. 

Zu den Daten des VAS-Container gehort ein globaler Key Generating Key KCKqec ^^^^ Terminals aller VAS- 

Provider zur Berechtigungspriifung der Operation "Entwerten" den Zugriffsschliissel K^ec erzeugen kann (mehr zur 45 
Schlusselableitung und Priifung folgt spater). An das Entwerten von geldwerten Daten werden nicht die gleichen Sicher- 
heitsmaBstabe wie an das Laden bzw. Erwerben eines Anspruchs gestellt. Es geniigt hier, anstelle eines applikationsei- 
genen Schliissels einen globalen Schlussel zu verwenden. Dieser globale Schliissel wird durch Ableitung zunachstin ei- 
nen Applikationsschliissel iiberfuhrt und anschlieBend durch emeutes Ableiten zum Terminalschliissel. Dem VAS-Pro- 
vider wird nur die applikation sspezifisc he Ableitung des globalen Schliissels zur Erstellung eigener Terminalschliissel 50 
iibermittelt. Dies wird nachfolgend kurz geschildert: 

Wir bezeichnen mit mac(k,d) die Berechnung eines Message Authentication C^ode fiir eine Nachricht d und einen DES- 
Schltissel k mittels DES. Falls die Nachricht nicht langer als 8 Bytes ist, entspricht dies der Verschliisselung selbst 
(ICV=0 vorausgesetzt). Wir bezeichnen mit macp(k,d) die Berechnung von inac(k, d) mit anschheBender Angleichung 
der Paritatsbits. Das Ergebnis k* = macp(k,d) ist wieder ein gultiger DES-Schliissel. 55 
Die Berechnung des applikationsspezifischen Terminalschliissels geschieht dann wie folgt: 

1. Jede Karte speichert einen Schliissel 
KGKdec. 

der fur alle Karten gleich ist und der das Geheimnis des System Operators ist. Der System Operator veranlaBt, daB 
dieser Schlussel in die Karte personalisiert wird. 

Aus diesem Schliissel konnen samtUche VAS-Applikations- und Tenninalschliissel abgeleitet werden. 

2. Ein VAS-Provider mochte eine VAS-Applikation A mit AID^=RIDvas ' P^^a einfiihren. Nun berechnet der Sy- 65 
stem Operator aus dem Schlussel KGKqec ""^ der PIX den applikationsspezifischen Schliissel 

KGK^PCPix = macp(KGKDEC' PI^a) 

und iibergibt diesen Schliissel dem VAS-Providen 
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3. Dieser VAS -Provider leitel aus KCK^i^t;;; pjx fur aile Teniiinals, die das TRANS FER-Koiuiiiando auf die VAS- 
Applikaiion A anwenden sollen, mil Hilfe ihrer Temiinal ID ihre spezifischen Schlussel ab: 

^DEC ~ '^^^P(^^^DEC,PIX' Terminal ID) — niacp(niacp(KGK|^g(-, PDC^), Teniiinal ID). 

Der VAS-Provider speichert diese Schlussel in seinen Terminals. Sofem der VAS-Provider nicht selbsl die Teniii- 
5 nals betreibi, gcnerierl er die Schliissel iind verteiit sie an die Betreiber der Tenninals. 

4. Die VAS-Karte fiihrt das TRANSFER Kornmando nur durch, wcnn das Kominando ein vom Terminal erzeugles 
Kryplogramin C enlhall, das iiber beslimmle Datcn data der Nachrichl im Translcrspeicher gebildet wird. Die Karte 
selbst kenni KCK^g^ und bekomm! von einem Tenninal neben den Nulzdatcn data und dem Kryptograiiim C die 
Tenninal ID sowie die PDv geschickl (bzw. die Karle kenni die PIX selbsU siche hierzu auch die Beschreibung des 

10 Koinmandos TRANSraR). Nun kann die Karle das Kryptogramm C iiber die Nuizdaten seibsi berechnen: 

mac(macp(macp(KGKQE(-,PIX), Terminal ID),dala) = = mac(macp(KGK£3g(- pj^, Terminal ID),data) = = 
niac(Ki)g(-,data) = ~ C 

Die Karte vergleicht nun das selbst berechnete Kryptogramm C mil dem vom Tenninal berechneten Kryptogramm C. 
15 Sind sie unterschiedlich, erfolgt ein Abbruch der Transaktion mil einer Fehlermeldung. Im Falle der Ubereinstimmung 
wird die VAS-Karte das TRANS FER-Kommando ausfuhren. 

Die unterschiedlichen Sicherheitsmal^stabe werden den unterschiedlichen Bauweisen von Serviceterminals bzw. 
Handlerterminals (zum Laden bzw. Erwerben) und einfachen Handlerterminals (zuin Entwerten) gerechL, Ein Terminal 
muB sich zur Ausfuhrung der "Entwerten" Operation gegeniiber der Karte durch Kenntnis eines Schliissels K^ec authen- 
2C tisieren. Bei Kompromittierung des Schliissels K^g^ kann der Angreifer lediglich die Funktionen dieses einen Terminals 
durchfuhren. Dieser Vorgang wird jedoch in der Karte protokoUiert. Die Dokumentation enthalt eine eindeutige Se- 
quenznummer, die Entwertung und die Tenninal ED. Die VAS-Applikaiionen nutzen die Sicherheitsdienste des VAS- 
Containers, um den Zugriff auf VAS-Daten zu reglementieren. Die Ausfiihrung von VAS spezifischen Funktionen wird 
durch die Definition von Zugriffsrechten auf berechtigte Parteien beschrankt. 
25 Im allgemeinen muB es fur jede VAS-Apphkation offentlich zugiingliche Datenbereiche (z. B. zum Auslesen von Wer- 
Len iiiit einem Wallet) und private Datenbereiche des verantwordichen VAS-Provider geben, die er vor dem ZugrilT durch 
andcrc schiitzcn kann (z. B. interne Vcnvaltungsdatcn). 

Da Karten nach ISO 7816-4 fiir einzelne Records von Elementary Files (EF) keinen difYerenzierten Zugriff sschutz bie- 
ten, miissen mehrere Dateien, die jeweils einen Record enthalten, zur Darstellung unterschiedlicher Sichien auf eine 
30 VAS-Applikation verwendet werden. 

So laBt sich fiir die Applikationsklassen Punktespeicher, Ticket, Ausweis und Datenspeicher differenzierter Zugriffs- 
schutz durch die Aufteilung der VAS-Daten in vier Elementary Files realisieren, wie in Fig. 6 dargestellt. 
Die vier Elementary Files enthalten folgende Daten bzw. werden folgendeniiaBen geschiitzt: 

35 



40 



45 



50 



55 



fiO 



65 
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Tabelle 3 
Ubersicht Dateien 



Feld 


Inhalt 


Typische Nutzung 


Zugriffsschutz 


EF_KEY 


EnthSIt die 
Schlussel 

^LVASP* ^RVASP 

die nur der 

VAS-Provider 

kennt 

(Anmerkung: 
Pro VAS- 
Applikation 
und optional 
pro Karte 
vergibt der 
VAS-Provider 
jeweiis ein 
Schlusselpaar 

) 


Ein VAS-Provider muR sich mit 
KLVASpQ*-*thentisieren, bevor er 
VAS-Daten schreiben darf in 
EFJNFO, EFJNTERNAL und 
EF VALUE bzw. bevor er Daten 
aus EF_INTERNAL iesen darf. 

Ein Terminal muli sich mit 
KRVASpaut^entisieren. bevor es 
VAS-Daten aus EF INFO. 
EF_VALUE iesen darf. 






Nli/^ht intern A 

Informationen 
uber die VAS- 
Applikation 


• f iO]\t^lll llUI 1 1 lallUi Icl 1 

• Bonusprogramm Information 

• Ausweisinformationen 

• Parkschein Informationen 


Dip Inhnitf^ HiPQpr npfpnpinhpit 

kdnnen nur vom VAS-Provider 
geschrieben (externe 
Authentifizierung durch Kenntnis 
von Klvasp) werden. Lesen soli 
nur an Terminals, die uber Krvasp 
Oder Kso verfugen, mdglich sein, 
Oder der Karteninhaber gibt einen 
konrekten PIN ein. (Der PIN- 
Schutz kann von Karteninhaber 
deaktiviert werden.) 


EF.INTERNAL 


Interne Daten 
der VAS- 
Appllkation 


Interne Zahler, Kontostande, 
Steuerinformationen, zusatzliche 
Keys fur: 

• Bonusprogramme 

• Rabattstaffeiungen 

• Verdeckte Ausweismerkmale 

• Codes 


Die Inhalte dieser Dateneinhelt 
konnen nur vom VAS-Provider 
beschrieben und gelesen werden. 
Der Zugriffsschutz basiert auf ex- 
terner Authentifizierung durch 
Kenntnis von Ki.vasp- 


EF VALUE 


Werte i n h eite n 
der VAS- 
Applikation 


Diese Dateneinhelt enthalt 
buchbare Werte einer VAS- 
Provider Appllkation. 

• Kontostand 

• Restwert Fahrschein 

• Guthaben 

• Nutzungszahler 


Nur der VAS-Provider kann diese 
Werte expiizit schreiben (exteme 
Authentifizierung durch Kenntnis 
von Klvasp)- Implizit kann der Wert 
durch den Befehl ..Entwertung" 
von einenrj Partner verringert 
werden, der zur Ausfuhrung der 
Funktion durch den VAS-Provtder 
berechtigt wurde (durch Signatur 
der Operation Entwertung mit 
Kdec)* Lesen wie bei EF INFO. 



Diese Struktur von FJeiTientary Files (FF) unTerstutzt die gleichen differenzierten ZugrifFsrechte fur alle Applikations- 
klassen. 

Indeni nun gleichartige Applikationsklassen zu jeweiis einer Implement ierungsklasse, die Anzahl und GroBe der Ele- 
mentary Files festiegt, zusammengefaBt werden, laBt sich ein Speicherverschnitl durch unterschiedlichen Platzbedarf fiir 
Applikationen minimi eren. Die Applikationsklassen Punktespeicher und Ticket benotigen die gleichen Resourcen 
EF_KEY, EF_INFO, EF.INTERNAL, EF__ VALUE und werden daher zusamniengefaBt zur Implement ierungsklasse 
*'DF_PT". Fur die Applikationsklassen Ausweis und Daienspeicher genugen die Elementary Files EF_KEY und 
EF_INFO und werden daher zur Implenientierungsklasse "DF„AD" zusamniengefaBt. AnzahlmaBig betrachtet: Es gibt p 
Objekte der Implementierungsklasse DF_PT und a Objekte der Implenientierungsklasse DF^AD, in die VAS-Apphka- 
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lionen der Appiikationsklassen Punklespeicher und Ticket bzw. Ausweis und Datenspeicher geladen werden konnen. 

Spcziell fur die Applikalionsklasse Gulschein, die offenlliche Lesczugriffe fur alle VAS-Teilnehmer zuin genicinsa- 
inen Datenaustausch enthalten soli, wird die Iniplemenherungsklasse Transferfeld vcrwendet. SchreibzugrifTe sind aus- 
schlieBlich indirekl durch die Anwendung des TRANSFT^R Befehls moglich, der eine Signatur niit einem korrekten 
5 Kqp(- verlangl. Diese Jnipleinenlierungsklasse besleht aus genau eineni Einlrag ini Elementary File EF_1T^NSFER, 
das zu den globalen Dalen des VAS-Conlainer gehort. Die Objekte dieser Klasse sind Records in dieser Dalei. Wir nen- 
nen diese luiplenienlierungsklasse auch "EF_TRANS1^R". 

Es gibt die in Fig. 7 dargestellten Iniplenienlierungsklassen innerhalb des VAS-Container. Diese Impleineniierungs- 
k las sen bilden das Speicheniiodell des VAS-Conlainer. 
10 Die Bereitstellung deni Speichemiodells kann auf zwei Arien erlolgen. Die Wahl hangi von der Kartenplaufonii ab: 

- Feste Partiiionierung des Speicherbereichs fur den VAS-Conlainer: 

Fur die TtyipleTnentierungsklassen DF_PT und DF_AD wird votn Issuer jewei Is ihre iriaxintale Anzahl p hzw. a von 
Ob jeklen feslgelegl und diese vom Issuer auf die Karle mil CREATE FILE Befehlen geladen. Die Objekte notieren 
15 wir mil DF_PTj bzw. DF_ADi. VAS-Applikalionen konnen zu einem spaleren Zeitpunkt in freie, also nicht von an- 

deren VAS-Applikationen belegle Objekte geladen werden. Zum Laden bzw. Loschen von VAS-Applikalionen sind 
dann nur UPDATE RECORD Befehle notwendig. 

Der Issuer legt also die Anzahl von moglichen Objeklen der beiden Implementierungsklassen nach seinen eigenen 
Bediirfnissen fest; dies kann eventuell nicht mil dem tats ach lichen VAS-Nutzungs verb alien des Karleninhabers 

20 ubereinslimmen. Die Aufteilung wird iiber den gesamten Lebenszyklus der Karle beibehalten. Eine VAS-Applika- 

tion wird in ein Objekl geladen, das von einer geeigneten Implenienlierungsklasse ist. So kann z. B. eine VAS-App- 
likation, die einen Ausweis darstellt, auch in einem Objekl der Implementierungsklasse DF__PT unleigebracht wer- 
den, wenn keine Objekte der Implementierungsklasse DF_AD (mehr) zur Verfugung slehen. Die Zuweisung einer 
VAS-Applikalion zu einem Objekl erfolgt durch den Einlrag eines Tripels (PIX der VAS-Applikalion, FED des be- 

25 leg ten Objekles, Klartextname der Applikation) in die globale Dalei EF_DIR des VAS-Conlainer. Das Entfemen der 

Applikalion entspricht dem Enlfernen dieses Tripels aus EF_DIR und dem zerstorenden Lesen (durch UPDATE 
RECORD Bcfehlc) des von der Applikation bclcgtcn Spcichcrs. 

Diese Variante findet Verwendung bei Kartenplattfonnen, die keine dynamische Erzeugung bzw, Loschung von 
DF/EF Slrukluren unterstutzen. 

30 - Dynamisches Anlegen von Objeklen der Implementierungsklasse: 

Fiir jede zu ladende VAS -Applikation werden mit CREATE FILE Befehlen die fiir die zugrundeliegende Implemen- 
tierungsklasse benotigten Dateien angelegt. Beim Loschen der VAS-Applikation wird die von ihr belegle DF/EF 
vollstandig aus der Karte enlfernt und der Speicherplatz freigegeben. Die maximale Anzahl von Objeklen von Im- 
plementierungsklassen ist hier nicht explizit vom Issuer festzulegen und hangt nur vom zur Verfugung slehenden 

35 Speicherplatz der Karle ab. 

Diese Variante erfordert eine dynamische Speicherverwaltung durch das Karlenbetriebssyslem, 

Im vorliegenden Ausfiihrungsbei spiel gehen wir von der erslen Variante aus, da die zweite erhohte Anforderungen an 
die zur Verfugung slehende Kartenplattform siellt. Sleht eine dynamische Speicherverwaltung jedoch zur Verfiigung und 
40 ist sichergeslelll, daB sich durch das dynamische Anlegen von Objeklen mehr Speicher sparen laBt als die Verwaltung ko- 
slel, dann kann das bestehende Konzept iibemommen werden und bietet dem Karteninhaber mehr Flexibilitat. 

Im folgenden werden die Dalen stiukturen und Kommandos vorgesielll, mil denen sich der VAS-Container und die 
Funktionalitat der VAS-Kundenkarle gegeniiber anderen Systemkomponenlen realisieren lassen. AuBerdem werden fur 
typische Geschaftsfalle VAS-Operationen feslgelegl^ die die jeweilige Interaklion zwischen VAS-Container und Teniii- 
45 nal beschreiben. 

Fiir die Implementierung wird von folgenden Voraussetzungen ausgegangen: 

- An einem Handler! erminal stelll jede Karle, unabhangig von der Plaltfonii, die gleiche Daten- und Kommando- 
schnittsielle zur Verfugung. Die erforderlichen Kommandos sind daher in ihrer Kodierung eindeutig beschrieben. 

50 - Servicelemiinals sind fahig, die Kartenplatlfomi zu erkennen. Die Funktionalitat kann dalier durch spezifische 

Kommandos der Plaltfonii erreichl werden. Diese Vorgange sind daher teilweise infomiell beschrieben. Wie diese 
Funktion bereitgeslellt wird ist dem KartenhersteLler freigesteUt. 

In Fig. 7 werden hierzu schematisch verschiedene Implementierungsklassen des VAS-Conlainers dargeslellt. Fig, 8 
55 zeigl schematisch die Dateistruktur des VAS-Containers, Fig. 9 zeigt schematisch die Daleistruktur der Implementie- 
rungsklasse DF_FU Fig. 10 die Dateistruktur der Implementierungsklasse DF_AD. 

Der Zugriff auf die Dateien des VAS-Container wird explizit durch folgende Access Conditions (AC) eingeschrankt: 
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Tabelle4 
Zugrifisbedingungcn 



Datei 


ADMIN 


Lesezugriff 


Schreibzugriff 


DF VAS 


Kso 


NEV 


NEV 


EF ID 


Krd 


ALW 


Kso 


EF DIR 


Kso 


ALW 


Kso 


globale KEYs 


Kfin 


NEV 


Kso 


PIN 


Kso 


NEV 


Kso 


EF VERSION 


Kco 


ALW 


Kso 










EF SEQ 




ALW 


Kso 


EF TRANSFER 




ALW 


Kso 










DF X 

(X=PT„...,PTo,ADi,...,ADa 
) 


Kso 


NEV 


NEV 


EF KEY 


Kc;n 


NEV 


Kso 


EFJNFO 


Kso 


PIN Oder Krvasp 
Oder Kso 


Klvasp 


EF INTERNAL 


Kso 


Klvasp 


Klvasp 


EF_VALUE 


Kso 


PIN Oder Krvasp 
Oder Kso 


Klvasp 



Dabei haben die AC folgende Bedeutung: 

35 

- ALW (Always) = Der ZugritT des Koniinandos auf die Datei ist immer erlaubl. 

- NEV (Never) = Der Zugriff des Koniinandos auf die Datei ist nie erlaubt. 

- Ks;o = Vor Zugriff niuB exteme Authentifizierung des System Operator mit dem Schlussel K^q erfolgen. 

- Klvasp - Zugriff muB exteme Authentifizierung des VAS-Provider mit dem Schlussel Klvasp erlolgen. 

- Kf^VASP - Zugriff muB exteme Authentifizierung eines vom VAS-Provider autorisierten Tenninals mil dem 40 
Schlussel Krvasp erlolgen. 

- PIN = Vor Zugriff niuB die konekte PIN durch den Kaiteninhaber eingegeben werden und im Klaj tcxt mit dem 
Komniando VERIFY an die Karte geschickt. werden. 

- PIN Oder Krvasp ^^^^ ^SO = Zugriff niuB entweder die korrekte PIN durch den Karteninhaber eingegeben 
werden, oder es erfolgt eine exteme Authentifizierung durch den VAS-Provider mit Krvasp o^er durch den System 45 
Operator mit K^q- 

Dabei ist anzumerken, daB die Oder-Verknupfung von Zugriffsrechten, wie oben beschrieben, in Kartenbetriebssyste- 
men in der Regel nichl vorgesehen ist. Evenluell bedeutet dies besonderen Implementierungsaufwand. (Altemafive: spe- 
zielles READ Kommando mit implizit festgelegteni Sicherheitsattribut). 50 

Datenfelder innerhalb der Records von Elementary Files werden nach folgenden Formaten unterschieden: ASCII, Bi- 
nar, BCD, Datum, Fomiatslring. 

Datenelemente vom Typ "Fonii at string" enthalten VAS-Daten in gepackter Darstellung, die dem Karteninhaber am 
Temiinal angezeigt werden konnen, 

Zur optimalen Speicherausnutzung werden Klartext und binare Daten gemischt und uber Fomiatiemiakros darstellbar 55 
gemacht. 

Sanitliche Elementary Files (EF) des VAS-Container sind nach ISO 78 16-4 deflniert als lineare toriiiatierte EF Dateien 
mit Records konstantcr Lange (linear fixed record files). 

Das Elementary File EF_ID des DF_VAS besteht aus einem Record, der die VAS-Container ID enthalt. 

Das Elementary File EF_DrR des DF_VAS besteht aus nr^jR Records. Fiir jede in den VAS-Container geladene VAS- 60 
Applikation wird in einem Record des EF_DIR ihr Proprietary Identifier Extension (PIX) und ihr physikalischer Spei- 
cherplatz (FID desDF_X, in den die Applikation geladen wurde) festgehalten. Die PIX identifiziert z. B. als Kcnnzifter 
die Applikation und den Service-Provider, dem die Applikation zugcordnet ist. 

Die Eintrage im EF_DIR werden am Service Temiinal des System Operators dynamisch angelegt. Records ohne Ein- 
trag werden mit einem leeren 'IT^V Objekt '61' angelegt 65 

Beim Laden einer VAS-Applikation wird zunachstein freier Speicherbereich der fur sie passenden Iiviplenientierungs- 
klasse gesucht, bestinnnte VAS-Daten dort eingetragen und schlieBlich in» EF_DIR ein neuer Record erzeugt. 

Beim Loschen einer AppHkation muB in EF_DIR entsprechend ein leeres TLV Ob jekt geschrieben werden. 

15 
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Das Elenieniary File EF_VERSION des DF_VAS bestehi aus einem Record, der eine Vcrsionsnuninier des VAS-Con- 
l ainer enihall. 

Die Versionsnuninier kann von Teniiinais dazu benut zt werden, verse hiedene VAS-Conl ainer- Variant en und/oder ver- 
schiedene Software- Versionen zu unterscheiden. 
5 Das Elementary File EF_SEQ des DF_VAS besteht aus einein Record, der die Nunimer des nrichsten TranslVfeldein- 
Irags en t halt. 

Die Sequenznummer wird voni Erganzungskoinniando TRANSFER ausgelesen. Dieses Kommando erzeugt. daraufliin 
ini Translerfeld EF_TRANSFER einen Record, in den u. a. die Sequenznunintcr aus EF_SEQ ubertragen wird. Zusaiii- 
iiien niit deiii Koiiiniando 1 AKH, das sicherstellt, daB jeder Record aus deni 'Iransferield nur einmal entnommen wird 
10 und diese Entnahiiie per Signaiur iiber die Sequenznummer dokumentieri, kann die einmalige Entnahnie von (Original-) 
CJutscheinen bzw. Quittungen garantiert werden. 

Ini folgenden soli nun genauer auf den Transferspeicher eingegangen werden. 

Der Transferspeicher wird innerhalb des VAS-Containers angelegt und unit^Rt nr^p transfer Records. Eintrage in 
den Records dieses Files enthallen Transferdaten, die vom TRANSFER Konmiando erzeugt werden. Uber den Transfer- 
15 speicher wird sowohl der Datenaustausch zwischen VAS-Applikationen als auch die Speicherung von VAS-Daten der 
Klasse Gutschein abgewickelt 

Der Transferspeicher kann ohne Beschrankung gelesen werden, der schreibende Zugritf ist jedoch nur durch die VAS- 
spezifischen Komiiiandos TRANSFER und TAKE moglich. 

Die Belegung der Datenfelder durch den TRANSFER Befehl geschieht durch einen "Last-recently- used" Algorithmus 
20 in der Karte. Der alteste Record in der Dalei kann durch Suchen des kleinsten Wertes in den ersten 2 Bytes des Records 
erinittelt werden. 

Datenfelder konnen mil dem Befehl "TAKE" im Transferspeicher als entnommen und/oder entfernl markiert werden. 
In jedem Fall erfolgt das Lose hen von Daten im Transferspeicher durch Uberschreiben mil neuen Daten. 

Jeder Record im Transferspeicher enthalt beispielsweise ein Verfallsdatum, die Terminal-ID, die FIX, die Sequenz- 
25 nummer und eventuell weitere Dalen. 

Jedes Elementary FileEF_INFO innerhalb von Verzeichnissen DF_X (mit X = PTj, . . PTp, ADj, . . AD^) bestehi 
aus cincin Record, der das Verfallsdatum sowic allgeiticinc VAS-Daten cincr VAS-Applikation enthalt. Beispielsweise 
kann die Art eines Tickets (Einzel- oder Streifenfahrschein) oder der Einsteigeort hier angegeben werden. EF_INFO muB 
jedoch zumindest einen Klartextnamen der Applikation enthalten, der fiir die Operation Ansehen VAS-Applikationen 
30 auslesbar ist. Sensible Daten muB der VAS-Provider durch geeignete exteme Verschlusselungsalgorithmen schiitzen. 

Dieses EF ist lesbar, wenn eine exteme Authentifizierung mit K^q oder K^yasp erfolgt oder der Karleninhaber im 
Falle eines aktivierten PIN-Schutzes eine korrekte PIN eingibt. 

Jedes Elementary File EF_INTERNAL innerhalb von Verzeichnissen DF_X (mit X = PTj, . . PTp, AD,, . . AD^) 
besteht aus einem Record, der interne VAS-Daten des VAS-Provider uber seine geladene VAS-Applikation enthalten 
35 kann. Weder Karteninhaber noch ein anderer VAS-Provider konnen diese internen Daten lesen. 

Jedes Elementary File EF_ VALUE innerhalb von Verzeichnissen DF_X (mit X = PT,, . . PTp, ADj, . . „ AD^) be- 
steht aus einem Record, der ein ganzzahliges Wert f eld der VAS-Daten enthalten kann. Dieses EF ist lesbar, wenn eine ex- 
teme Authentifizierung mit K^q oder Krvasp erfolgt oder der Karteninhaber im Falle eines aktivierten PIN-Schutzes 
eine korrekte PIN bzw. ein korrektes PaBwort eingibt. 
40 Die folgenden Schlusselfelder werden vom VAS-Container oder von der VAS-Applikation benutzt, Im folgenden wird 
von einerreinen DES-Verschlusselung ausgegangen. D.h. samtliche Schlussel des VAS-Containers sind DES-Schltissel 
und sind in 8 byte codiert (einschlieBlich Paritatsbits). 

Innerhalb des VAS-Containers und innerhalb der VAS-Applikationen konnen folgende Schliissel durch ihren KID 
(Key Identifier) referenziert werden: 

45 

Tabelle 5 
Schlussel VAS-Container 

50 



KEY 


KID 


Kso 


*00' 


Kaijt 


•or 




'02' 


KGKnen 


■03' 



Jeder Schlussel ist mit einem Fehlbedienungszahler verknupft Dieser registriert fehlgeschlagene Authentifizierungs- 
fiO versuche mit diesem Schliissel und blockiert eine weitere Nutzung, wenn ein Limit fur diesen Zahler eingetragen und er- 
reicht ist. 

Innerhalb der VAS-AppHkation konnen folgende Schlussel durch ihren KID referenziert werden. 
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Tabelle 6 
Schlussel VAS-Applikalion 



KEY 


KID 


^LVASP 


'04' 




'05' 



Jeder Schlussel ist mil einem Fehlbedienungszahler verkniipft. Dieser registriert fehlgeschiagene Authenlifizlerungs- 
versuche niit diesern Schlussel und blockiert seine weilere Nut/.ung, wenn ein TJTnit fiir diesen Zahler eingetragen und 
erreicht ist. 

Der VAS-Container enlhalt eine personliche Idenlifikationsnuinmer oder PaBwort (PIN). Dies wird vom VERIFY 
Komniando zur Identifikation des Karteninhabers benutzt. Die PIN ist verknupft mil einem Fehlbedienungszahler, der 
jede Falscheingabe registriert und bei Erreichen eines Limits den PIN- Vergleich sperrl. Diese Sperre kann durch den Sy- 
stem Operator mil geeigneten Administrationskomniandos zuriickgesetzt werden. Der Fehlbedienungszahler wird bei 
korrekt eingegebener PIN zuriickgesetzt . 

Es gibt folgende Parameter fiir den VAS-Container, die vom Kartenherausgeber geniaB deni zur Verfiigung stehenden 
Plalz auf einer Kartenplattform und seinen individuellen Wunschen gewahlt werden konnen: 

- p Maxiinale Zahl von Objekten der Implementierungsklasse DF_PT = maximale Zahl von VAS-Applikationen 
der Applikationsklassen Punktespeicher und Ticket, die gieichzeitig in einen VAS-Container geladen werden kon- 
nen; 

- a Maximale Zahl von Objekten der Iiiipleiiienlierungsklasse DF_AD = iiiaxiiiiale Zahl von VAS-Applikationen 
der Applikationsklassen Auswcis und Datcnspcichcr, die gieichzeitig in cincn VAS-Container gcladcn werden kon- 
nen; r 

- nr^iR Maximale Gesamtzahl von Objekten: nr^iR = p + a. Die Anzahl von Records in EF_DIR ist nr^jj^; 
~ n^EF TRANSFER Anzahl von Records des EF_TRANSFER. 

Der Speicherbedarf fur die GroBen der beschriebenen Elementary Files ist: 



Globale Daten des VAS-Containers: 



to 



15 



25 



30 



Transferfeld: 

Proprietare Daten der VAS-Provider 





Byte 


EFJD 


4 


EF_DIR 


9 * (p+a) 


EF_VERSION 


1 


EF_SEQ 


2 


Globale Keys, Pin 


64+2 


EF_TRANSFER 


48 * nrgp TRANSPER 


EF_KEY 


(p+a) * 32 


EFJNFO 


(p+a) * 62 


EFJNTERNAL 


p * 10 


EF_VALUE 


p *3 



40 



45 



50 



55 



Wahlen wir z. B. I'ur die Parameter p, a und nr^p transfer tolgende Werte, dann ergibt sich iolgender Mindestspei- 
cherbedarf fiir den VAS-Container (ohne Speicherbedarf fiir Erganzungskommandos): 



Parameter Speicherh>edarf 

p = 8, a = 3, nrEF_TRANSFER = 15 2030 Byte 

p = 10, a = 5, nrEF_TRANSFER = -'^58 Byte. 

Der Maximalspeicherbedarf ist wahrscheinlich urn ca. 10% hoher als der Mindestspeicherbedarf. 

Im folgenden wird nun genauer auf die Kommandos der ertindungsgemaBen Chipkarte eingegangen. 

Das READ RECORD Komraando wird zum Auslesen von Daten aus linearen Elementary Files benutzt. Die Karte lie- 
fert in der Ruckantwort den Inhalt des Records. Das EF wird durch den Short File Identifier (SFI) referenziert. 

Der Status Code '9000' signaHsiert eine erfblgreiche Durchfuhrung des Konmiandos; jeder andere Code wird als Feh- 
ler bewertet. 
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Der UPDATE RECORD Befehl wird benutzU uiii Dalen in die Records eines linearen EF ein/ubringen. Die Koiiiinan- 
donachrichl enihall die Referenz auf das EF, den Record und die Daten. 

Die Ant wort der Karte enthall den Statuscode. Der Slaluscode *9000' signalisierl den erfolgreichen AbschluB der Koiii- 
niandos. Andere Staluscodes zeigen den Fehlerfall an. 
5 Das GET CHALLENGE Koininando fordert von der Karte eine Zut^llszahl an. Die Ziil^llszahl wird ini Ziisaninien- 
hang mil der dynainischen Authenlifizierung ini EXTERNAL AUTHEN^FICATE verwendei. 

Die Ant worlnachricht der Karle enlhalt eine 8 byles langeZulallszahl und den Slaluscode. Der Slaluscode '9000' zeigl 
die erfolgreiche Ausfuhrung des Koniniandos an. Andere Staluscodes zeigen den Fehlerfall an. 

Das Konirnando EX TERNAL AUTHEN'riCArE eriaubldie Authenlifizierung eines renninals gegenubcr der Karle. 
to EXTERNAL AUTHENTICATE wird im Rahmen von VAS-Applikalionen zur Authenlifizierung des System Operalors 
und des VAS-Providers benulzl. EXTERNAL AUTHENTICATE uberiragi ein Kryplogranini in die Karle, das zuvor 
vom Tenninal durch Verschlusseln einer Zufallszahl erzeuglwerden muB. Die Karte vergleichl das Kryplogranun inilei- 
nerii Referenzwerl, den sie selbsl nach dem gleichen Verfahren berechnet hal. Sind beide Werte gleich, so venTierkl die 
Karle intern, daB die Zugriffsbedingung Aulhentifizierung fiir diesen Schlussel erl'olgl isl. Sollte der Vergleich negativ 
15 ausfallen, so gibt die Kane den Status "Nichl autorisiert" zuruck und dekreine n fieri einen inlemen Fehlbedienungszahler. 
Erreichl dieser Zahler den Wert 0, so wird jede weitere Ausfuhrung des EXTERNAL AUTHENTICATE mil deni Status 
"Authenlifizierung gesperrl" abgewiesen. 

Die Antwortnachrichider Karte enthall den Slaluscode. Die erfolgreiche Durchfuhrung des Komniandos und die Au- 
thenlifizierung der Temiinals gegeniiber der Karte wird durch den Slaluscode '9000' angezeigt. Andere Staluscodes zei- 
20 gen den Fehlerfall an. 

Das Komiiiando INTERNAL AUTHENTICATE wird benutzt, urn die Echtheit des VAS-Containers durch ein Tenni- 
nal prufen zu konnen. Die Karte berechnet dazu ein Kryptogramni uber Referenzdalen voin Terniinal. Das Terminal bil- 
dei seinerseits das Kryplograntm und vergleichl es mil dent Wert von der Karle, Bei Gleichheit kann das Tenninal die 
Echtheit des VAS-Containers annehmen. 
25 Die Antwort der Karle enthall das Kryplogramin und den Slaluscode fur die Ausfuhrung des Kommandos. Die erfolg- 
reiche Durchfuhrung des Kommandos wird durch den Slaluscode '9000' angezeugU Andere Staluscodes zeigen den Feh- 
lerfall an. 

Das VERIFY' Kommando wird zur Verifikation der Karleninhaber PIN benulzl. Das Kominando ubertragt die PIN Da- 
ten unverschllisselt an die Karle, wo ein Vergleich mit eineni gespeicherten Referenzwerl durchgefiihrt wird. Sind einge- 
30 gebener und gespeicherter Wert identisch, so wird die Zugriffsbedingung "PIN" als erfiilil betrachtet. 

Die Antworlnachricht der Karte enthalt den Statuscode. Der Slaluscode '9000' zeigl die erfolgreiche Durchfuhrung des 
Kommandos an, Andere Staluscodes zeigen den Fehlerfall an. 

Das TRANSFER Kommando erzeugt einen Eintrag im Transferspeichen Drei Arbeitsmodi sind fur das Kommando 
definiert: 

35 

1. Erzeugen eines Eintrags im Transferfeld durch Verringem von Werten im EF_VALUE Feld der Applikation der 
Klasse Ticket oder Punktespeicher. 

2. Erzeugen eines Eintrags im Transferfeld durch Erslellen einer Quitlung in Applikalionen der Klasse Ausweis. 

3. Erzeugen eines Eintrags im Transferfeld durch Erslellen eines Gulscheins in AppUkalionen der Klasse Gut- 
40 schein. 

Der Arbeitsmodus wird durch die Kane automatisch ausgewalilt : Wird der Befehl innerhalb eines selektierten Appli- 
kaiions-DF ausgefiihrt, so wird zunachst das Vorhandensein eines EF_VALUE iiberpriift. Bei vorhandenem EF_VALUE 
fiihrt die Kane den Befehl im Modus 1, ansonsten im Modus 2 durch. 1st innerhalb des VAS-Containers kein Applikati- 
45 ons-DF ausgewahll, wird Modus 3 benutzt. 

Das Tenninal versorgt die Kane beim Aufruf des TRANSFER Kommandos mit den Iblgenden Daten: 

- Aktuelles Datum 

- Verfallsdatum fur den Eintrag im Transferfeld 
50 - Identifikation fur das Terminal, welches diesen Eintrag erzeugt 

- Nulzdaten fiir das Transferfeld 

- PIX der VAS-Applikalion (niir Modus 3) 

- Anzahl abzuziehender Einheiten (nur Modus 1) 

- MAC Liber die o.g. Daten, die Sequenznummer und die VAS-Container Numnier. 

55 

Die Karle fiihrt beim Aufruf des TRANSFLiR Komniandos die folgende Sequenz aus: 

1. Suchen nach einem freien Eintrag im Transferspeichen (Die folgende Aufzahlung gibt absteigend die Prioritat 
wieder, in welcher vorhandene Einlragungen iiberschrieben werden sollen: "Eintrag ais enlfernt markierl", "Eintrag 
als entnonimen markierl" und "Verfallsdatum erreichl", "Verfallsdatum erreicht"). 

2. Anhangen der PIX an die Daten vom Tenninal in den Modi 1 und 2. 

3. Anhangen der Sequenznummer an die Daten aus Schritt 2. 

4. Anhangen der VAS-Container ID an die Daten aus Schritt 3. 

5. Ableilen des KOK^gc durch Verse hi tisseln der PIX unter dem KOK^ec 

6. Ableilen des K[)g(- durch Verschlijsseln der Tenninal ID unter dem KGKj^gQpj^. 

7. Erzeugung des MAC iiber die Daten aus Schritt 4. 

8. Vergleich des MAC aus Schritt 7 mit dem MAC vom Terminal. Sind die Werte unlerschiedlich, bricht die Karte 
die Funktion ab und verringert den Fehlbedienungszahler fiir den KCiK^ec- 

18 
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9. Fur Modus 1: Priifung des Wcrtfeldes EF_VALUE iin Verzeichnis, in das die Applikation geladen wurde. Sind 
nichi genugend Einheiten in dieseni Feld vorhanden, brichl die Kane die Funktion an dieser Sietle ab. Andemfalls 
wird das Wenfeid in der Applikation uin den Betrag vermindert. 

10. Zusanimensiellen der Konniiandonachricht. 

11. Inkrenientieren des Tnhalts von EF_SEQ uni 1. ^ 

Die Konimandonachricht enthalt bcispielsweise Feider init eineni Verfallsdatunu der Terminal ID, den Transakiions- 
daien, ein Feld fur den Betriebsniodus (enthalt z. B. im Modus 3 die PDC), sowie ein Kryptograinni. 

Das Kryptograinni wird unter Verwendung des Schlussels K^ec berechnet, wobei die Daten, iiber die der MAC gebil- 
dei wird, beispielsweise die Transaktionsdaten und die Tenmnal-ED unifassen. lo 

Die Ant.wortnachricht des TRANSFER Koniniandos unifaBt ini Erfolgsfall einen 8 Byte langes Datenfeld und den 
2 Byte langen Statuscode '9000'. Antworinachrichten niit einein von '9000' verschiedenen Statuscode werden als Fehler- 
code interpretiert. Das Datenfeld der Antwortnachricht enthalt ini fehlerfreien Fall (d. h. insbesondere war das Krypto- 
grainni der Konimandonachricht korrckt) das mit Kj^gc verse hlusselte KryptogramiTi der Komniandonachricht . Dadurch 
wird iniplizit (anstelie einer internen Authentifizierung mit K^yj) ein Echtheitsnachweis durch den VAS-Container er- 15 
bracht. 

Das KoiiuTiando TAKE dient zur Entnahnie von Objekten aus der Inipiementierungsklasse EF_TRANSFER, Tech- 
nisch bedeutet die Ausfuhrung des Koimiiandos TAKE das Auslesen eines anzugebenden Records aus der Datei 
EF_TRANSFER, wobei der Record in der Datei so lange verbleibt , bis der Speicherplatz fur neue Eintrage benotigt wird, 
der Datensatz wird als entnomnien markiert. Technisch gesehen kann jeder das Kommando TAKE nutzen, urn einen Da- 20 
tensatz zu entnehmen, nach den R&,R soUte dies jedoch nur ein VAS-Provider tun, fur den der Datensatz bestimmt ist. 

Fiir den Entnahmevorgang kann folgendes angenoinnien werden. Der VAS-Provider, der einen Gutschein oder eine 
Quittung entnehinen will, durchsucht den Transferspeicher nach einera passenden Datensatz (z. B. durch das Kotiiinando 
SEEK oder durch explizites Lesen jedes Records). Der Datensatz wird in jedeiii Fall gelesen und eventuell inhaltlich ge- 
pruft. 25 

Die Ausgabe des Dalensalzes in der Anlwort ist daher nithl notwendig. Es kann weilerhin angenoiianen werden, daB 
die Nummcr des Records bckannt ist. 

Das Kommando TAKE stellt folgende Modi bereit: 

- Entnahme mit gleichzeitigem Vennerk, daB die Daten ungultig geworden sind. . 30 

- Entnahnie ohne vorstehenden Vemierk. Die Daten bleiben weiterhin gultig. 

Die Kommandonachricht enthalt Feider mit Terminal-ID, PIX der Applikation und eine vom Terminal generierte Zu- 
faUszahL 

Die PIX im Kommando bezeichnet die entnehmende Anwendung. Sie darf verschieden sein von der PIX des Daten- 35 
satzes, der entnornmen wird. Sie dient ausschlieBlich zur Ableitung von K^ec entnehinenden Handlerteniiinals. 

Die Antwortnachricht der Karte enthalt ein Kryptograinni Ci mit Ks7g_vasc ^^^^ Daten des in der Kommando- 
nachricht angegebenen Records des Transferfeldes und die VAS-Container ED, ein Kryptogramin C2 mit Kp>pf: ent- 
nehinenden Terminals uber Cj und die Zufallszahl aus der Kommandonachricht. Die Ant wortnachricht enthalt zusatzlich 
den Statuscode. Der Schliissel K^g^ wird wie vorher beschrieben abgeleitet. Mit dem Kryptograimii vermoge Kj^g^ 40 
wird implizit ein Echtheitsnachweis durch den VAS-Container erbracht. Mit dem Kryptogramm C wird ein Echtheits- 
nachweis und Einmaligkeitsnachweis (da C iiber Sequenznumnier, Entnonimen-Bit des Transferfeld-Records und VAS- 
Container ID gebildet werden) berechnet, den der Systemoperator verifizieren kann. 

Der Statuscode '9000' zeigt die erfolgreiche DurchflihrLing des Kommandos an. Andere Statuscodes werden als Fehler 
interpretiert. ^5 

Es ist davon auszugehen, daB der SO eine AIDvas gemaB ISO/IEC 7816-5 beanlragt. Genauer: Er beantragt eine 
5 Byte lange RIDvas VAS- System. 

Die AIDyas Verzeichnisses DF_VAS soil lauten: AIDvas = I^J^vas ' P^^df^vas- 

Fiir jede VAS- Applikation A wird gemaB RO eine 3 Bytes lange PIX a vergeben, um sie innerhalb des VAS-Container 
eindeutig mit AID;^ = RIDyAS * PI^A identifizieren zu konnen. Nach der Selektion des DF_VAS kann ein Verzeichnis, in 50 
dem die VAS -Applikation A enthalten ist, mit SELECT FILE <PIX^> ausgewiihlt werden. 

Mit dem UPDATE KEY(KID, K) sei ein von der Kartenplattform abhangiges Kommando bezeichnet, mit welchem 
ein Schliissel mit Key Identifier ID durch den neuen Wert K ersetzt wird. 

Bevor eine VAS- Applikation aus einer der Implementierungsklassen DF_PT oder DF_AD (dies entspricht den Appli- 
kationsklassen Punktespeicher, Ticket, Ausweis oder Datenspeicher) durch den Karteninhaber an Handlerterminals ge- 55 
nutzt werden kann, muB sie an einein Serviceteniiinal des zustandigen VAS-Provider in den VAS-Container geladen wer- 
den. Prinzipiell ist auch moghch, daB ein Karienherausgeber im Auftrag eines VAS-Provider und eines SO bereiis beim 
Aufbringen des VAS-Containers eine oder mehrere VAS-Applikationen in den VAS-Container ladt. Dieser Ladevorgang 
ist ein Spezialfall des hier beschriebenen. 

Ablauf des Fadens einer VAS-Applikation: <>0 

1. Karteninhaber fiihrt eine VAS-Karte in ein Servicetenninal ein. 

2. Das Servicetenninal pruft, ob ein VAS-Container vorhanden ist: 

- SELECT FILE <AIDvas> (Fehlenneidung wenn VAS-Container nicht selektierbar) 

- READ RECORD <SFI von EF_ID, 0> (Auslesen der VAS-Container Numiiier). 65 
Optional wird die Giiltigkeit des VAS-Containers gepruft. Dazu verlangt das Servicetenninal eine interne Au- 
thentifizierung des VAS-Containers: 

- INTERNAL AUTHEN^riC:ATE <Zufallszahl, KID von Kaut> 
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Das Servicetenuinal priift die Ant wort und bricht ini Fehlert^Il (niit Fehlenneldung) ab. 

3. Das Servicelenninal stellt dein Karteninhaber mehrere Optionen zur Auswahl. Einc davon lauiet Laden VAS- 
Applikation. Diese wahit der Karteninhaber aus. Nun werden deni Karteninhaber alle VAS-Applikationen, die am 
Serviceteniiinai geladen werden konnen, angezeigt, und es wird auf cine Auswalil gewartet. Dazu wird die Opera- 

5 tion Ansehen VAS-Apphkationen aktiviert. Der Karteninhaber wahit eine VAS-Applikation A der Iinplenientie- 

rungskiasse DF FT oder DF AD aus. 

4. Das Serviceteniiinai untersucht den VAS-Container iitit der Operation Selektion einer VAS-Applikation, ob die 
ausgewahhe VAS-Applikation niit PDC^ bereils in der Karte geladen ist. Falls ja, wird eine Fehlenneldung ausge- 
geben. Halls nicht, wird geprult, ob noch ein Objekt der tiir A geeigneten Inipleiiientierungsklasse im VAS-Conlai- 

10 ner frei ist. Dies geschiehi durch Suchen eines freien Records in EF_DIR (z, B. mil deiii Koininando SEEK). Falls 

nichts frei ist, wird eine Fehlenneldung ausgegeben. Falls ein Record Irei ist, enthalt dieser eine nD^p x cin^s 
DF_X, in das keine VAS-Applikation geladen ist. 

5. Das nachste freie Objekt der fiir A geeigneten Tniplenient.ierungsklasse wird belegl fur die VAS-Applikation A. 
Dabei erfragt zunachst das Servicetemiinal offline vom VAS-Provider (z. B. durch ein VAS-Provider-SAM) zwei 

15 Schlussel K| Y^sp und Kj^y^^p und weist sie der neuen VAS-Applikation zu: 

- SELECT FILE <FrDDp x> 
~ GET CHALLENGE 

- EXTERNAL AUTHENTICATE <Kso(ZufaIlszahl), KJD von Kso> 

- UPDATE KEY <KrD von Klvasp- J^lvasp> 
20 - UPDATE KEY <KID von Krvasp Krvasp> 

- (5ETCHALLEN(JE 

- EXTERNAL AUTHENTICATE <Klvasp (Zufallszahl), KID von Klvasp> 

- UPDATE RECORD <SFI von EF_INFO des DF_X, Daten> 

- UPDATE RECORD <SFI von EF„INTERNAL des DF_X, Daten> 

25 - Optional (Initialisierung): UPDATE RECORD <SFI von EF_ VALUE des DF_X, Daten>. 

6. Nach dein erfolgreichen Schreiben in die EEs wird voin Serviceteniiinai die Operation Einlrag VAS-Applikation 
<PIX A, FIDdf_x> ausgcfuhrt, die das DF_X mit deni PIX^ vcrbindct und so SELECT FELE niittcls des PDC^ (nach 
der vorherigen Selektion mit SELECT FTLE AIDy^g) ermoglicht. 

Der mil deiii Transferspeicher zur Verfugung gestellte Mechanismus laBt sich z. B. von VAS-Providern nutzen, die In- 
tra- oder Interservices ohne proprietare DF-Strukturen abwickeln iiiochten. Ein Karteninhaber muB dann insbesondere 
vor der Benutzung einer VAS-Applikation diese nicht erst an einem Serviceteniiinai laden. Er kann dagegen direkt am 
Handlerteniiinal sich einen Gutscheinoder eine Quittung ausstellen und dies an einem anderen Terminal erstatten (durch 
die Operation Entnehmen) lassen oder den Gutschein bzw. die Quittung nur einfach vorweisen (durch Lesen). Das Laden 
einer VAS-Applikation der Implementierungsklasse EF_TRANSFER wird daher implizit durch Aufbringen von VAS- 
Daten realisiert bzw. auf diese Operation zuruckgefuhrt. Hierzu wird auf die spater folgende Beschreibung des Erwer- 
bens der Implementierungsklasse EF^TRANSFER verwiesen. 

Nachfolgend wird der Ablauf der Operation des Eintrags einer VAS-Applikation beschrieben. 

Ist eine VAS-Applikation in den VAS-Container geladen, ist einem Terminal der physikalische Ort unbekannU in wel- 
chem DF_X mit X = PTj,. . PTp, AD|, . . AD^ die VAS-AppHkation bzw. ob sie uberhaupt geladen ist. Aus Sicht des 
Kartenherstellers sind zwei mogliche Implemenlierungsweisen moglich, die getrennl gepruft werden soUen; dabei ist 
insbesondere die Konsislenz zum ZKA-Standard zu beachten. 

Der erste Fall: Zugriff auf EF^DIR mogHch 

Folgende Voraussetzungen sind zu erfullen: 

- Es gebe standardmafiig in der Kartenplattform ein EF_DIR (z. B. unter DF_VAS), in dem AIDs den FIDs der 
DF_X zugeordnet sind, in denen sich VAS-Apphkationen aktuell befinden. 

- Dieses EF_DIR ist fur jeden Icsbar (AC von READ RECORD: ALW). 

- Wird eine VAS-Applikation A mit PIX^^ voin System Operator in ein freies (unbenutztes) DF_X geladen, d. h, 
die vorhandenen Elementary Files dieses DF_X beschrieben (kein CREATE FTLE !), dann soli durch ein UPDATE 
RECORD die Datei EF DIR uin den Eintrag PIX^^ erweitert werden konnen, der auf dieses DF X verweist mit 
FTDx- Die AC von UPDATE RECORD sollte daher eine exteme Authentisierung mil dem Schlussel K^q erzwin- 
gen. 

- Wird der Belehl SELECT FILE <PDC^> nach der vorherigen Selektion von DF_VAS an die Karte iibeniiittelt, 
muB das DF_X, in das eine VAS-Applikation A geladen ist, direkt selektierbar sein. 

- Wenn eine VAS-Apphkation A, die in DF^X und den darunterliegenden Elementary Files geladen ist, auf 
Wunsch des Karteninhabers an einem Service- Terminal geloscht werden soil, werden die enisprechenden Dateien 
nicht mit DELETE FTLE geloscht, sondem die eingetragenen Dalen lediglich mit Dummy-Werten iiberschrieben. 
Danach soli aus EF_DIR der Eintrag PlXy^ (genauer das Paar PIX^ und der Verweis auf DF_X) geloscht werden 
konnen (z. B. durch UPDATE RECORD mit vorheriger extemer Authentisierung mit dem Schlussel K^q). 
~ Da die Anzahl der DF_X fest ist, ist die Anzahl der Records von EF_DIR bekannt. 

Ist dieser Ansatz realisierbar, ergibi sich folgende Konsequenz: 

- Ein nach Selektion von DF_VAS direkt erfolgcndes Selektieren einer VAS-Applikation mit SELECT FTLE PlXy^ 
ist moglich. 
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Der zweite Fall: Zugriff auf EF_DIR nicht nioglich 

Steht bei der Kartenplatttbnn kein EF_DrR zur Verfiigiing oder ist kein lesender und schreibender Zugriff auf dieses 5 
EF DIR - wie ini obigen Abschnitt dargesteilt - nioglich, soli es unter DF VAS eine Datei EF VASDER geben, in der 
vorn System Operator durch explizite UPDATE RECORD Befehle (nach vorheriger extemer Authentifizierung niit K^q) 
ein Bezug der PDC^ geladener VAS-Applikationen zu ihrem physikalischeni Speicherplatz in eineni DF_X heigestellt 
wird. Das Ecsen und Loschen von Records aus EF_VASD1R soli wie vorher beschrieben inoglich sein. 

Der Ablauf der Operation Eintrag VAS-Applikation lauft wic Iblgl: lo 
Eine VAS-Applikation A initPDC^ wurde vorher in ein freies DF_X mitFTD^p x geladen. Die Nuinnierdes Records niit 
FrDi2)p X vvurde voni Service! enninal veniierkt. 

1. SELECT FILE <AIDvas> (Fehlemieldung wenn VAS-Container nicht selektierbar) 

2. GET CHALLENGE 15 

3. EXTERNAL AUTHENTICATE <Kso (Zufallszalil), KID von Kso> 

4. UPDATUt RECORD <SFI von EF^DIR des DF_VAS, Nuninier Record niit FTDdf^x^ ^^a^ ™^df x>' 

VAS-Applikationen der Implementierungsklassen DF_PT oder DF_AD konnen nur an Servicetemiinals (da unter Ho- 
heit des System Operator) auf Wunsch des Karteninhabers geloscht werden, VAS-Applikationen der Implementierungs- 20 
klasse EF_TRANSFER konnen iiberall und von jedeni geloscht werden. Beim Loschen zu unterscheiden sind V\S-App- 
likationen der Implementierungsklassen DF_PT und DF_AD bzw. der Implementierungsklasse EF_n^NSFER. 

Ablauf des Loschens einer solchen VAS-Applikation fur die Implementierungsklasse DF_PT oder DF_AD: 

1 . Der Karteninhaber fuhrt eine VAS-Karte in ein Servicetenninal ein. 25 

2. Das Servicetenninal priift, ob ein VAS-Container vorhanden ist: 

- SELECT FILE <AIDy^s> (Fchlcrmcldung wcnn VAS-Conlaincr nicht selektierbar). 

- READ RECORD <EF_ID> (Auslesen der VAS-Container ID). -: 

3. Das Servicetenninal stellt dem Karteninhaber mehrere Optionen zur Auswahl. 

Eine da von lautet Loschen VAS-Applikation. Diese wahlt der Karteninhaber aus. Nun werden dein Karteninhaber 30 
aile VAS-Applikationen aller Implementierungsklassen, die ini VAS-Container geladen sind, angezeigt, und es wird 
auf eine Auswahl gewartel, Dazu wird die Operation Ansehen VAS-Applikationen aktiviert. Der Karteninhaber 
wahlt eine VAS-Applikation A der Implementierungsklasse DF_PT oder DF_AD mit AID A aus. Das Objekt, in 
deni die VAS-Applikation geladen ist, heiBe DF_A. 

4. Nach der Selektion des DF_A authentisiert sich das Servicetenninal: . 35 

- SELECT FILE <PIX^> 

- GET CHALLENGE 

- EXTERNAL AUTHENTICATE <Kso Zufallszahl), KID von Kso>- 

5. Nun wird der Inhalt der Dateien aus DF_A geloscht (fur EF_KEY, EFJNTERNAL und EF„ VALUE sind der 
K^vASP notwendig, deshalb wird dieser zuerst vom System Operator geloscht): , 40 

- UPATE KEY <KID von K^vasp^ • •00"> 

- UPDATE KEY <KID von Krvasp "C)0. . .00"> 
GET CHALLENGE 

- EXTERNAL AUTHENTICATE <Klvasp (Zufallszahl), KID von Klvasp> 

~ UPDATE RECORD <SFT von EF_INFO des DF_A, "00. . .00"> 45 

- UPDATE RECORD <SFI von EF_INTERNAL des DF_A, "00. . ,00"> 

- UPDATE RECORD <SFI von EF_VALUE des DF_A, "00. , .00">. 

6. Nach eineni erfolgreichen Schreiben in die EEs wird abschlieBend vom Servicetenninal der Eintrag der VAS- 
Applikation aus EF_DIR geloscht: 

- SELECT FILE <AIDvas-^ (Fehlemieldung wenn VAS-Container nicht selektierbar) 50 

- UPDATE RECORD <SFI von EF^DIR des DF_VAS, Nummer Record mit FIDdp_a "00, . .00", FIDj^p a>. 

Die Verbindung von PIX^ zuni DF A wird dadurch aufgelost, so daR SELECT FILE mit dem PIX^ nicht mehr niog- 
lich ist. 

Nun fur die Implementierungsklasse EF TRANSFER: 55 
Eine VAS-Apphkation der Implementierungsklasse EFjrRANSFER soli nach R&R nur auf expUziten Wunsch eines 
Karteninhabers an einem Handlertemiinal oder Servicetenninal geloscht werden (auch wenn dies technisch durch beide 
moglich ware). Das Loschen eines Objektes aus EF^TK^NSFER wird insbesondere dann notwendig, wenn der Trans- 
ferspeicher keinen Platz mehr enthalt fiir die Speicherung eines neuen Objektes (z. B. einen Gutschein oder eine Quit- 
tung). Das Ixischen geschieht imnier indirekt iiber das Erganzungskomniando TAKE. Dieses Komniando niarkiert nur 60 
ein Objekt als entlcmt. Daniit ist es zum Uberschreiben durch ein nachlblgendes Ere:anzungskommando TRANSFER 
freigegeben. 

Ablauf des Loschens dieser VAS-Applikation: 

1 . Der Karteninhaber fuhrt eine VAS-Karte in ein Tenninal ein, welches den Inhalt von EF_TRANSFER darstellen 65 
kann (Spezialfali von Operation Ansehen VAS-Applikationen). 

2. Das Tenninal priift, ob ein VAS-Container vorhanden ist: 

- SELEC'TFELE <AIDvas> (Fehiemieldung wenn VAS-C'onlaincr nicht selektierbar) 
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- READ RECORD <SH von EF_ID, 0> (Auslesen der VAS-Coniainer ID). 

3. Das Terniinai si ell! deni Karleninhaber niehrere Optionen zur Auswahl. Eine da von lautcl Loschen VAS-Appli- 
kation. Diese wahlt der Karleninhaber aus. Nun werden dein Karleninhaber zuniindestens die VAS-Applikalionen 
der Iitiplementierungsklasse EF_TRANSFER angezeigt, und es wird auf eine Auswahl gewarlel. Dies wird durch 

5 einen Spezialfall der Operation Anschen VAS-Applikationen realisierl. Der Karleninhaber wahlt ein Objekl der Ttn- 

plenienlierungsklasse mil eineni Gulschein bzw. einer Quill ung aus. Dieses Objekt besitze die Recordnuinnier A. 
Der Karleninhaber beslaligl die Auswahl. 

4. Das Teniiinal niarkiert den Record mil Recordnummer A als entlernt, indeni cs A, eine von ihni berechnele Zu- 
lallszahl, seine PDC und iemiinal ID mil dem Koniinando TAKE ubemiillell: 

10 - TAKE <A, Zufallszahl, PDC, Terminal ID>, 

Nun stehrder als enlfernl markierte Record wieder zur Verfiigung zur Aufnahme fiir einen neuen Gulschein oder eine 
Quiltung. 

Nachfolgend der Ablauf der Seleklion einer VAS-Applikation: 
15 Isl eine VAS-Applikalion A der Implemenlierungsklassen DF_PT oder DF_AD in den VAS-Container mil der Operation 
Laden VAS-Applikation geladen worden, kann sie zweistufig von eineni Terminal selektierl werden. Zuersl wird der 
VAS-Container selektierl und danach die VAS-Applikation mil ihrer PDCys^^: 

1. SELECT FILE <AIDy;^s> (Fehlenneldung wenn VAS-Container nichl selektierbar) 

20 Ein Servicelenninal kann die Echtheil des VAS-Conlainers prufen. Dazu verlangl ein Servicetemiinal eine interne 

Authentifizierung des VAS-('onlainers: 

- READ RECORD <SFI von EF_ID, 0> (Auslesen der VAS-Conlainer ID) 

- INTERNAL AUTHENTICATE <Zufallszahl, KID von Kaut>- 

Das Serviceterminal priifl die Antwort und bricht im Fehlerfall (mil Fehlenneldung) ab. 
25 2. SELECT FILE <PIX^> (Fehlenneldung, falls VAS-Applikation A nicht in den VAS-Container geladen ist). 

Ein Handlcrtcrminal (welches nicht iibcr den KGK^yj vcrfiigt) kann indirckt die Echlhcil des VAS-Containcrs durch 
die Echtheitspriifung der VAS-Applikalion A feststellen. Denn eine VAS-Applikation kann nur an einem Serviceterminal 
geladen worden sein, die beim Ladevorgang die Echtheit des VAS-Containers gepruft hat. Die Echlheitsprufung der 
30 VAS-Applikation A kann auf den Test des Handenenninals zuriickgefiihrt werden, ob der VAS-Container den Schlussel 
^LVASP ^^^^ Krvasp f^"* VAS-Applikation A enthalt. Dies kann das Handlertemiinal z, B. kontroUieren durch: 

- INTERNAL AUTHENTICATE <Zufallszahl, KID von Krvasp oder Klvasp>- 

35 Um zu testen, ob eine VAS-Applikation A im VAS-Container geladen ist, kann sie probeweise selektierl werden; auf- 
grund der Fehlermeldung der Antwortnachricht von SELECT FILE kann daraus geschlossen werden, daB sie nicht vor- 
handen isl. 

Eine Seleklion einer VAS-Applikation der Implemenlierungsklasse EF_TRANSFER ergibt sich implizit durch die 
Operation Ansehen V^S-Applikationen und das Speichem der Daten im Terminal. Da das Terminal die Recordnummer 
40 von jedem angezeigten Objekt aus EF_TRANSFER kennt, kann per Recordnuimner ein beliebiges Objekt zur Weiter- 
verarbeitung durch Bezugnahine auf die Recordnummer selektien werden. 

Nachfolgend der Ablauf des Ansehens einer VAS-Applikation: 
Die Operation Ansehen von VAS-Applikationen listet an einem Servicelenninal samtliche VAS-Applikationen der Im- 
plemenlierungsklassen DF_PT, DF_AD und EF_TRANSFER auf. An einem Handlerterminal konnen nur die VAS-App- 
45 likalionen der Implemenlierungsklasse EF_TRANSFER angezeigt werden, da fur diese kein Zugriffsschutz existiert, 
und optional Applikaiionen der Iinplementierungsklasse DF_PT bzw. DF__AD, fur die das Handlerterminal Leserechte 
besilzt (Besilz von Kj^y^sp 

Ablauf einer solchen VAS-AppHkation: 

50 1 . Der Karleninhaber fiihrt eine VAS-Kane (Chipkarte mil gulligem VAS-Container) in das Terminal ein. 

2. Das Servicetemiinal pruft, ob ein VAS-Container vorhanden ist: 

- SELECT FILE <AIDvas^ (Fehlenneldung wenn VAS-Container nichl selektierbar) 

- READ RECORD <SFI von EE ID, 0> (Auslesen der VAS-Container ID). 

Optional wird die Gulligkeit des VAS-Containers gepruft, Dazu verlangl das Servicetertninal eine interne Au- 
55 thentifizierung des VAS-Containers: 

- IN TERNAL A UJHENTiC ATE <Zufallszalil, KID von Kaut>- 

Das Serviceterminal prtift die Antwort und bricht ini Fehlerfall (init Fehlenneldung) ab. 

3. Das Serviceterminal slellt dem Karleninhaber mchrere Optionen zur Auswahl. Eine da von laulet Ansehen V\S- 
Apphkalionen. Diese wahlt der Karleninhaber aus. 

60 4. Das ServicetenT>inal authentisiert sich: 

- GET CHALLENGE 

- EXTERNAL AUTHENTICATE <Kso (Zufallszahl), KID von Kso >• 

5. Fur VAS-Applikationen der Implenientierungsklassen DF_PT und DF_AD werden iiber den In halt von EF_DIR 
gesteuert nacheinander die einzelnen VAS-Apphkationen selekliert und nach einer externen Authentifizierung mit 

65 dem Schlussel K^q der Inhalt der einzelnen EFJNFO (oder ein Teil davon nach R&R) sowie EF_VALUE ange- 

zeigt: 

- Fur i = 0,. . ntQij^ - 1 
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- READ RECORD <SH von EE_DIR, i>. 

In der Aniworlnachricht steht PDC^^, die "00, . .00" ist, wenn in das entsprechende DF keine VAS-Appli- 
kalion geladen isl. Allernativ zum READ RECORD aus EF_DIR kann eventuell auch ein SEEK Koni- 
niando benutzl werden. 5 

- Wenn PIX^ ungleich "00. . .00" 

- SELECT FILE <PDC^> 

- SELEC'J'E1LE<P1Xa> 

- SELECT FILE <PDC^X> 

- SELECT FILE <PIX;i,> 

- READ RECORD <SFI von EF„ VALUE, 0> 

^ SELECT Fn.E<ATDvAS>- 
6. Fur VAS-Applikationen der Iiii piemen tierungsklasse EF__TRANSFER wird der Inhalt (oder ein Teil davon nach 
R&R) des EF_TRANSFER eines jeden Records gelesen: 15 

- SELECT FILE <AIDvAS> 
FUr i = 0, . . nr^F TRANSFER ~ 1 

- READ RECORD <SFI von EF_TRANSFER, i> (in der Antwortnacliricht steht Inhalt des i-ten Re- 20 
cords von EF_TRANSFER) 

- Wenn Inhalt nicht leer ist, w^ird der Inhalt interpretiert (z. B. entnominen/verf alien) angezeigt. 

Das Ansehen der Applikationen der Iinpiententierungsklasse DF_PT bzw. DF_AD, fiir die das Handlertemiinal Lese- 
rechte besitzt (Besitz von Krvasp)' erfolgt wie beschrieben - mit zwei Abweichungen: Zur extemen Authentifizierung 25 
wird anslelle des K^q, uber den nur der System Operator verfugt, der SchlQssel Kj^vASP benutzl. Verfiigt ein Handlerter- 
niinal nicht ubcr den KCK^uT mochtc dcnnoch die Echthcit der VAS-Applikationcn priifcn, kann das Handlcrtcr- 
niinal anstelle der internen Authentifizierung die Authentifizierung (zumindest einer) VAS-Applikation verlangen; Dies 
geschieht, wie aufgefuhrt, durch Kenntnis der Karte des entsprechenden Krvasp ^lvasp Schlussels. 

Fur VAS-Applikationen der Implemen tierungsklasse EF_TRANSFER wird der Inhalt (oder ein Teil davon nach R&R) 30 
des EF_TRANSFER jedes Records nacheinander aufgefistet, wie vorher beschrieben. 

Die Operation Interpretieren VAS-Applikationen verlauft dazu analog. Das Terminal stellt dazu dem Karteninhaber 
eine Option Interpretieren VAS-Applikationen zur Auswahl. Zusatzhch zu den Daten, die durch die Operation Ansehen 
sichtbar werden, konnen auch Daten aus EF_INFO und EE VALUE, die einer Interpretation durch den VAS-Provider 
bedurten (z. B. extern verschiusselte Daten) und Daten aus EF_INTERNAL (z. B. Meilen der vergangenen Jahre bei Mi- 35 
les & More), dargestellt werden. Dies ist jedoch nur fiir die VAS-Applikationen moglich, fur die ein VAS-Provider (nach 
seinen eigenen Vorstellungen) ain Temiinal geeignete SchlQssel zur Verfiigung stellt. Zum Lesen des EF_INTERNAL ei- 
ner VAS-Applikation ist der Schliissel K| vasp (exteme Authentifizierung) notwendig. Fiir extern verschiusselte Daten 
innerhalb der Elementar>' Files EF^INFO,' EF_INTERN und EF_ VALUE sowie des Transferspeichers EF_TRANSFER 
werden die entsprechenden Schlussel des VAS-Providers benotigt. Das Terminalprogramm kann anhand der PIX einer 40 
seleklierten VAS-Applikation ieicht entscheiden, fur welche Applikafionen Schlussel fiir die Interpretation der Daten zur 
Verfugung stehen. 

Die Operation Ubertragen von VAS-Applikationen bedeutet das Ubertragen aller oder ausgewahlter VAS-Operationen 
einer Quell-Karte auf eine Ziel- Karte an einem Serviceterminal. Bedingung ist hierbei, daB im VAS-Container der Ziel- 
karte keine VAS-Applikationen geladen sind und nach der Ubertragung auf der Quell-Karte alle VAS-Applikationen ge- 45 
loscht werden. Beides kann durch sukzessive Anwendung der OperaUon Loschen einer VAS-Applikation erreicht wer- 
den. AuBerdem muB die Echtheit der VAS-Karten gepriift werden und die Ziel-Karte iiber ausreichend Speicherplatz ver- 
fiigen. Die Operadon Ubertragung selbst basiert im wesentlichen auf einer Erweiterung der Operation Ansehen von 
VAS-Applikationen, bei der zusatzlich die Daten aus EF_INTERNAL und die Schlussel K^vASP Kry^^sp gelesen 
werden, und einer wiederholten Anwendung der Operation Laden einer VAS-Applikation. 50 

Mit den VAS-Daten wird auch die VAS-Container ID mit auf die Ziel-Karte ubertragen, daniit sich VAS-Applikatio- 
nen auf der Ziel-Karte genan so verhafien wie auf der Quell-Karte. Der Grund hierftir ist, daB von einem VAS-Provider 
abgeleitete Schlussel dich auf die VAS-Container ID stutzen, die Schlussel aber unverandert kopiert werden. AuBerdem 
mochte ein VAS-Provider seine Buchfuhrung im Hintergrundsystem nicht andern, da er VAS-Karten ublicherweise iiber 
die VAS-Container ID identifiziert. Unbedingt zu beachten ist bei der Ubertragung der VAS-Container ED, daB diese sy- 55 
stemweit eindeutige Nuinnter auf der Quell-Karte geloscht wird. 

Um speziell das Elementary File EF_INTERNAL und die Schlussel Krvasp K^y^sp lesen zu konnen, uber- 
schreibt das Serviceterminal nach einer extemen Authentifizierung mit dem Schlussel KgQ (analog wie bei der Operation 
Loschen einer VAS-Applikation) zuerst die Schlussel K^vasp kann dann nach einer emeuten Authentifizierung mit 
Klvasp Daten aus EF_TNTRRNAL ubertragen. 60 

Zusatzhch zu den VAS-Applikationen der Implement ierung ski as sen DF_PT und DF__AD muB die Datei EF_TRANS- 
FER ubertragen werden, Dazu werden mit der Operation Entnehinen nacheinander dieObjekte dieser Implenientierungs- 
klasse entfernt, die nicht bereits als entfemt oder verfallen markiert sind, ihre Signatur mit K^jq vasc gepriift und in das 
EF_TRANSFER der Ziel-Karte ubertragen. Auf der Ziel-Karte werden allerdings die Objekte als nicht entnommen ge- 
kennzeichnet, damit sie weiterhin gultig bleiben. 65 

SchlieBlich mussen noch die globalen Daten des VAS-Containers ubertragen werden. Insbesondere muB der Sequenz- 
zahler der Ziel-Karte auf den Wert der Quell-Karte eingestellt werden. 

Nachfolgend das Verfahren des Aufl^ringens von VAS-Daten: 
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Es gibl drei inogliche I alle fiir das AulT^ringcn von VAS-Dalen an eineiii Handlcrleniiinal, die von der Ar! der VAS-App- 
likalion abhangen. 

Zunachst das Erwerben ini Falle der Iinplenientierungskiasse DF_PT oder DF_AD 

5 

Es sollen von eineni VAS-Provider Daien in eine VAS-Applikation A der Iinplenientierungskiasse DP FF oder 
DF_AD geschrieben werden. 

Ablauf des Aufbringens von VAS-Dalen: 

10 1. Der Karieninhaber luhrt eine VAS-Kane in ein Handleneniiinal ein. 

2. Das TTandlerlcniiinal priift^ ob ein VAS -Container vorhanden ist: 

- SELECT FILE <AIDyas^ (Fehlenneldung wenn VAS-Conlainer nicht selektierbar) 

- READ RECORD <SFI von EE_TD, 0> (Auslesen der VAS-Container TD). 

3. Es wird die Echtheit des VAS-Containers geprufu 

15 Ist das Handlerterininal selbst in Besitz des Masterkeys KGK^uj, kann es eine interne Authentifizierung des VAS- 

Containers verlangen: 

- INTERNAL AUTHENTICATE <Zufaliszalil, KID von K^uT> 

Ein Handleneniiinal (welches nicht uber den KGK^yx verfugt) kann indirekt die Echtheit des VAS-Containers 
durch die Echtheitspriifung der VAS-Applikation A feststellcn. Denn eine VAS-Applikation kann nur an einem 
20 Serviceteniiinal geladen worden sein, die beim Ladevorgang die Echtheit des VAS-Containers gepriift hat. Die 

Echtheitsprufung der VAS-Applikation A kann auf den Test des Handlerteniiinals zuriickgefuhrt werden, ob 
der VAS-Container den Schliissel Klvasp ^^^^ ^rvasp VAS-Applikation A enthalt. Dies kann das 

Handlerteniiinal z. B. kontroUieren durch: 

- SELECT FILE <PIXa> (Fehlenneldung, falls VAS-Applikation A nicht in den VAS-Container geladen ist) 
25 - INTERNAL AUTHENTICATE <Zufallszahl, KID von Krvasp ^der Klvasp>- 

Das Handlerteniiinal priift die Aniwort und bricht iin Fehlerfall (mil Fehlenneldung) ab. 

4. Das Handlerterininal sclckticrt die VAvS-Applikation A, authcntisicrt sich und bcschrcibt die Elementary Files, 
die fur die Abwicklung der Transaktion notwendig sind: 

- SELECT FILE <PIXa> (entfallt, wenn bereits in Schritt 3 durchgefuhrt) 
30 - GET CHALLENGE 

- EXTERNAL AUTHENTICATE <Klvasp (Zufallszahl), KED von Klvasp> 

- optional: UPDATE RECORD <SFI von EF_INFO des DF_X, Daten> 

- optional: UPDATE RECORD <SFI von EF_INTERNAL des DF_X, Daten> 

- optional: UPDATE RECORD <SFI von EF„ VALUE des DF^X, Daten>. 

35 



Als nachstes das Erwerben im Falle der Implementierungsklasse EF„TRANSFER 

Speziell fiir VAS-Applikationen der Implementierungsklasse EF_TRANSFER (AppUkationsklasse Gutschein) iiiuB 
40 ein VAS-Provider keine proprietare Daieistruktur DF_X fiir seine Applikation belegen. Die Folge ist, daB ein Kartenin- 
haber nicht vor der Nutzung einer VAS-Applikation Gutschein an ein Servicetemiinal gehen iiiuB, um eine VAS- Appli- 
kation zu laden. Er kann dagegen direkt am Handlerteniiinal sich einen Gutschein oder eine Quittung ausstellen und 
diese an eineiii anderen Terminal erstatten (durch die Operation Entnehmen) lassen oder den Gutschein bzw. die Quit- 
tung nur einfach vorweisen (durch Lesen). Durch das Aufbringen von VAS-Daten erfolgt somit ein implizites Laden von 
45 VAS-Applikationen der Implementierungsklasse EF_TRANS1^R. Fiir diese Apphkationsklasse existiert die Implemen- 
tierungsklasse EF_TRANSFER, die aus einzelnen Objekten der Art Record besteht. Ein Eintrag in EF__TRANSFER ist 
ausschheBlich durch das Kommando TRANSFER mogUch. Das Handleneniiinal muB dazu im Besitz eines gultigen Ent- 
werter-Schlussels Kf^g^ sein und uber eine PIX^ der VAS-Applikation A verfugen. 
Ablaut des Aufbringens von VAS-Daten: 

50 

1. Der Karieninhaber fiihrt eine VAS-Kane in ein Handlerteniiinal ein. 

2. Das Handlerlerininal priift, ob ein VAS-Container vorhanden ist: 

- SELECT FILE <AIDvas> (Fehlenneldung wenn VAS-Container nicht selektierbar) 

- READ RECORD <SH von EFJD, 0> (Auslesen der VAS-Container Nummer). 

55 3. Das Handlertenninal liest die Sequenznumiiier, die zusatzlich in den MAC aus Schritt 4 eingeht: 

- READ RECORD <SFI von EF_SEQ, 0> (Auslesen der Sequenznu miner). 

4. Mit dem Koiiimando TRANSFER wird in EF_TRANSFER ein Record geschrieben: 

- TIMNSFER <Transaktionsdatuni, Verl^allsdatum, Erzeugercode, Daten, PIX^, MAC mil KQgQ> 

5. Das Handlertenninal kann durch Priifung der Antwonnachricht des TRANSFER Kominandos prufen, ob der 
60 VAS-ContBiner echt ist (d. h. in Resit/, des gemeinsamen Geheimnisses K^j^^ ist). Wir verweisen hierz.u auch auf 

die vorher beschriebene Antwonnachricht des Kommandos TRANSFER. 



SchlieBlich das Erwerben von VAS-Daten durch Enlwerten 

65 

Ein VAS-Provider kann durch einen Ent wertevorgang mit dem Kommando TRANSFER iin Transferfeld EF^TRANS- 
FER ein Anrecht (z. B. Gutschein oder Quittung) erzeugen, das von einem anderen VAS-Provider weiter verwertet wer- 
den kann. Ent wertet werden Daten aus dem EF_ VALUE bzw. EF_INFO der VAS-Applikation A des ent wenenden VAS- 
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Provider. Dcr Karteninhaber erwirbl in Form eines Objektes in EF„TRANSFER das Anreclil. 
Ablauf des Aufbringens von VAS-Dalcn: 

1. Der Karteninhaber ruhrt eine VAS-Karte in ein Handlertemiinal ein. 

2. Das Handlertemiinal priift, ob ein VAS-Container vorhanden ist: 5 

- SELECT FELE <AIDvas> (Fehlenneldung wenn VAS-Container nichl selektierbar) 

- READ RIiCORD <SH von EFJD, 0> (Auslesen der VAS-Container ID). 

3. Das Handlerteniiinal liest die Sequenznuiiiiiier, die zusatzLich in den MAC aus Schritt 4 eingeht: 

- READ RECORD <SF1 von EF_SEQ, 0> (Auslesen der Sequenznuininer). 

4. Das ?Iandleriemiinal selektierl die VAS-Applikation A: lo 

- SELECT FILE <PIXa> (Fehlenneldung, falls VAS-Applikation A nichl in den VAS-Container geladen ist), 

5. Das Handlertenninal nutzt das Konimando TRANSTOR zuni Entwerten der Daten aus deni EF__V\LUE bzw. 
deiii EF_TNFO. 

- TRANSFER <Dalen, MAC niit KDec>- 

Die Zusamniensetzung der Kominandonachricht von TRANSFER wurde bereits beschrieben. Die Berechti- 15 
gung zum Enlwertevorgang erlangt das Tenuinal, wenn es eine korrekte Signatur Uber die Daten mil deni 
Schlussel Ki^EC bilden kann. Diese wnd durch den VAS-Container gepriifl. Bei Erfolg wird voni VAS-Contai- 
ner ein Record in EF_TOANSFER angelegi sow^ie die Sequenznuninier inkrenientierl. 

6. Das Handlertemiinal kann durch Prufung der Antv^'ortnachricht des TRANSFER Koinniandos prufen, ob der 
VAS-Container echt ist (d. h. in Besitz des genieinsainen Geheininisses K^g^ ist). 20 

Und nun noch das Verfahren zuni Entwerten von VAS -Daten. Es gibt zwei Art en von Entwertungsvorgangen: 

Zum einen konnen VAS-Daten fur VAS-Applikationen der Iinpleiiientierungsklasse DF_PT oder DF_AD durch den 
zugehorigen VAS-Provider entwertet werden durch die Operation Entwerten, d. h. Erwerben von VAS-Daten durch Ent- 
werten. Dadurch wird ein Wert verbraucht, wobei ein potentielles Anrecht auf einen weiteren Wert entsteht. 25 

Zum anderen konnen VAS-Daten aus dem EF_TRANSFER einnialig entnoiinnen werden niit deni Erganzungskom- 
mando TAKE. In dicseni Fall wird das Anrecht aufgcbraucht, die Daten blcibcn fur ctwaigc wcitcrc Vcrwcndung (z. B. 
ruckerstattetes Ticket wird zur Riickfahrt noch benotigt) im Transferfeld als entnomnien gekennzeichnet stehen, bis sie 
bei Bedarf von anderen Objekten uberschrieben werden. 

Ablauf des Entwertens von VAS-Daten durch das Komniando TAKE: 30 

1. Der Karteninhaber fiihrt eine VAS-Kane in ein Handlertemiinal ein. 

2. Das Handlertenninal priift, ob ein VAS-Container vorhanden ist: 

- SELECT FILE <AIDy^s> (Fehlenneldung wenn VAS-Container nicht selektierbar) 

- READ RECORD <SF1 von EF_ID, 0> (Auslesen der VAS-Container ID). 35 

3. Zunachst liest das Handlerterminal die zur Verfugung stehenden Objekte aus EE TRANSFER aus mit deni Spe- 
zialfall der Operation Ansehen VAS-Applikationen, uni zu entscheiden, ob ein gesuchtes Objekt enthalten ist. Al- 
ternativ kann mit dem Kommando SEEK nach eineni Muster gesucht werden. Das Terminal kennt im Erfolgsfall die 
Nummer i des gesuchten Records. 

4. Das Tenninal markiert den Record mit Recordnummer i als entfernt, indem es i, eine von ihm berechnete Zu- 40 
fallszahl, seine FIX und Terminal ID mit dem Kommando TAKE ubermittelt: 

- TAKE <i, Zufallszahl, FIX, Terminal ID>. 

Das Handlenerminal nutzt das Kommando TAKE zum Lesen der Daten aus dem EF_TRANSFER bei gleichzeitigem 
Kennzeichnen der Daten als entnomnien. Die Ausfuhrung des Koinmandos bewirkt zusatzlich die Erzeugung von zwei 45 
verschiedenen Kryptcgramnien Cj und C2. 

Das Kryptogramm C] wird durch den VAS-Container mit dem Schlussel K^iq vasc berechnet. Damit kann der Ein- 
reicher des entnommenen, mit C| signierten Objektes sich beim System Operator die EinmaHgkeit und Echtheit nach- 
weisen lassen. Die Einmaligkeit und Echtheit der Transaktion ergibt sich aus dem Kryptogramm des VAS -Providers, von 
dem das Objekt ursprunglich stammt (und die von der Karte gepriift wurde, siehe TRANSFER), und der Fiihrung eines 50 
Sequenzzahlers liber die Transaktionen sowie deni Kryptogramm Cj durch die Karte bei der Entnahnie. 

Das Kryptogramm C2 wird durch den VAS-Container mit dem Schlussel Kq^c berechnet, der von dem VAS-Contai- 
ner aus KGKdeC' Terminal ID abgeleiiet wird. Durch Kenntnis des gemeinsanien Geheimnisses K^ec kann der 
VAS-Container dem Terminal gegeniiber direkt die Echtheit des VAS-Containers beweisen. Da beim TRANSFER Kom- 
mando ebenfalls gepriift wird, daB nur echte Gutscheine bzw. Quittungen in einen echten VAS-Container gespeichert 55 
werden, kann daraus die Echtheit des entnommenen Objektes gefolgert werden. Da C2 indirekt uber die Sequenznum- 
mer, das Entnommen-Bit und die VAS-Container ID gebildet wird, kann der VAS-Container dem Teniiinal sogar die Ein- 
maligkeit des entnommenen Objektes nachweisen. 

Die Bcrechtigung zum Entnehmen mit dem Kommando TAKE hat jeder. 

Am Servicetemiinal ist femer die Deaktivierung bzw. Aktivierung eines PaRwort- oder PTN-Schutv^s fur das T^sen 60 
von VAS-Applikationen der Iinplementierungsklassen DF_Fr und DF„AD mogHch. AuBerdem kann die PIN des VAS- 
Containers vom Karteninhaber durch der Kenntnis der PIN geanderl werden und vom System Operator mittels extemer 
Authentifizierung durch K^q zuriickgeselzt werden. Als PIN oderPaBwort sind auch nicht-numerische 2^ichen oder Zei- 
chenketten belie biger Lange verwendbar. 



Patentanspriiche 

1. (^hipkarte, die zur Durchfuhrung von Transaktionen dient, bei denen geldwerte Einheiten oder andere nicht-nio- 

25 
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net are Anspruche reprasentierende Werldaten zwischen deni Karteninhaber und niindestens eineni Transakiions- 
parlner (Service-Provider) ubertragen oder dem Service-Provider zur Verifizierung der Anspruche vorgewiesen 
werden, wobei die Chipkarte einen Speicher unifaBu in dem zur Durchfuhrung der Transakiionen erforderliche Da- 
ten abgespeicliert werden, und die Chipkarte dadurch gekcnnzeichnct ist^ daB sie folgendes aufweist; 
5 cine Einrichtung zuin Laden von einer oder niehreren Kartenimwendungen (VAS-Applikationen) ant- die Karte, die 

jeweils die Durchfuhrung von Transakiionen zwischen dem Karteninhaber und einem oder niehreren Service-Pro- 
vider eniioglichen. 

2. Chipkarte nach Anspruch 1, bei der die Einrichtung zum Laden folgendes aufweist: 
cine darin abgespeicherte Datenslruktur {DF_VAS, VAS-Container), die aufweist: 

10 eine Teilstruklur (DF_PT, DF_AD, VAS-Applikalion), in die zur Emioghchung der Durchfuhrung einer Transak- 

tion zwischen dein Karteninhaber und einem Service-Provider erforderliche Dalen (VAS-Daten) geladen werden 
konnen; 

einen Definilionsdatensatz, der Tntomnationen iiher die Art und/oder Strukiur der in der Teilstruklur (VAS-Applika- 
tion) abgespeicherten Daten enthalt; wobei der Definitionsdatensatz femer aufweist: 
15 eine die Datenslruktur (VAS-Container) und/oder die Chipkarte identifizierende Kennung (Container-ID); und 

inindestens einen System-Schlussel (K^o)' der die Integritat des Definitionsdatensalzes und/oder der Datenslruktur 
(VAS-Container) gegen Modifikationen absichert. 

3. Chipkarte nach Anspruch 1 oder 2, dadurch gekennzeichnet, daB sie femer aufweist: 

einen Transfer-Speicherbereich (EF_TRANSFER) zur Aufnahme von bei der Durchfuhrung der Transaktion auszu- 
20 tauschenden oder vorzuweisenden die geldwerte Einheiten oder nicht nionetaren Anspruche reprasentierenden Da- 

ten; und 

eine Einrichtung zum Schreiben von Daten in den Trans ferspeicher in Reaktion auf ein Schreibkominando (Trans- 
fer). 

4. Chipkarte nach einem der Anspruche 1 bis 3, dadurch gekennzeichnet, daB sie weiterhin mindestens eines der 
25 folgenden Merkmale aufweist: 

eine Einrichtung zum Laden von fiir die Durchfuhrung von Transakiionen erforderhchen Daten in die Teilstruklur 
untcr Vcrwcndung des mindestens cincn Systemschlusscls; 

eine Einrichtung zum Schreiben von Daten in den Definitionsdatensatz zum Anpassen der Daten des Definitionsda- 
tensalzes an die in die Teilstruktur geladenen Daten; 
30 eine Einrichtung zum Generieren einer weiteren Teilstruktur, in die zur Durchfuhrung einer Transaktion erforderli- 

che Daten geladen werden konnen, in dem Speicher der Karte; und/oder 
eine Einrichtung zur dynamischen Speicherverwaltung auf der Karte. 

5. Chipkarte nach einem der vorhergehenden Anspruche, dadurch gekennzeichnet, daB 

es sich bei den Teilstrukturen (VAS-Applikationen) um voneinaiider unabhiingige Teilstrukturen handelt, die je- 
35 weils einem bestimmten Service-Provider zugeordnet sind, 

der Definitionsdatensatz iiiittels des mindestens einem Systenischlussels (Ksq) gegen Modifikationen geschiitzt ist 
und nur mittels dieses Schlussels modifiziert werden kann, und daB 

das Laden der Teilstrukturen (VAS-Applikationen) nur unter Verwendung des im Definitionsdatensatz enthaltenen 
Systemschltissels erfolgen kann. 
40 6. Chipkarte nach einem der vorhergehenden Anspruche, dadurch gekennzeichnet, daB der Definitionsdatensatz 

femer mindestens eines der folgenden Merkmale aufweist: 

mindestens einen Authentifizierungsschlussel (K;!^ut) Authentifiziemng der Berechtigung der Chipkarte gegen- 
iiber einem Tenninal und/oder zur Authentifizierung der Berechtigung eines Tenninals gegeniiber der Chipkarte; 
mindestens einen Signierschliissel (K^jq vasc) ^Lim Signieren von aus dem Transferspeicher entnommenen Daten; 
45 einen Schlusselerzeugungs-Schlussel (KGKdec) Erzeugung von terminal- und applikationsspezifischen 

Schlusseln zur Uberpriifung der Berechtigung eines Schreibvorgangs in den Transferspeicher und/oder einer Ent- 
wertung von Wertdaten; 

eine PIN zur Verifikation der Berechtigung eines Transaktionsvorgangs durch den Karteninhaber, 
daB der Systemschlussel (K^o):. der Aulhentizifierungsschlussel (K^ut)' Signierschliissel (Ksjg vasc) ""^ 
50 Schlusselerzeugungs-Schiiissel (KCK^gc) kartenindividuelle oder datenstruktur-(DF_VAS)-spezifische Schlussel 

sind, und daB die Teilstruktur (VAS-Applikation) mindestens eines der folgenden Merkmale aufweist: 
mindestens einen Wertspeicher (EF_VALUE) zur Aufnahme von Wertdaten; 

mindestens einen Intern-Speicher (EF INTERNAL) zur Aufnahme von intemen die Teilstruktur betreffenden Da- 
ten; 

55 itiindeslens einen Infospeicher (EF_INFO) zur Aufnahme von nicht intemen die Teilstruktur betreffenden Daten; 

einen Schlusselspeicher (HF_KliY) zur Aufnahme mindestens eines Schlussels (Klvasf^ ^RVASp)' Schreib- 
und/oder Lesevorgange in den oder aus dem Wertspeicher, und/oder dem Intem-Speicher und/oder dem Info-Spei- 
cher absichem, und daB die Chipkarte femer umfaBt: 

eine Einrichtung zum Schreiben und/oder Lesen von Daten in den oder aus dem Wertspeicher, dem Intem-Speicher 
60 und dem Infospeicher, und daB die Einrichtung zum Laden umfaBt: 

eine Einrichtung zum Schreiben der Schlussel in den Schlusselspeicher unter Absicherung durch den niindestens ei- 
nen Systemschlussel. 

7. Chipkarte nach einem der vorhergehenden Anspruche, dadurch gekennzeichnet, daB die Teilstruktur mindestens 
eines der folgenden Merkmale aufweist: 

65 einen Schlussel (K^vASp) ^'^"^ Uberprtifen der Schreibberechtigung von Daten in die Teilstruktur; 

einen Schlussel (K^vASp) 2"'" Uberprtifen der Leseberechtigung von Daten aus der Teilstruktur. 

8. Chipkarte nach einem der vorhergehenden Anspriiche, dadurch gekennzeichnet, daB die im Schlusselspeicher 
abgespeicherten Schlussel fur die jeweilige Teilstruktur spezifisch sind und daB die mindestens eine Teilstruktur 
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(VAS-Applikation) das Durchfuhrcn von Transaklionen niiuels niindestens eines dcr spezifischen Schlussel 
(Klvasp Krvasp) absichert, der fur die jeweilige Teilstruklur (VAS-Applikalion) spezifisch und von den SchlUsseln 
anderer Teilslrukturen (VAS-Applikationen) unabliangig ist. 

9. Chipkarte nach eineni der vorhergehenden Anspriiche, dadurch gekcnnzeichnel, daB 

die Karte inehrere der Teilslrukturen (VAS-Applikationen) aulwcist, die jeweils zur Diirchfiihrung von Transaklio- 5 
nen zwischen eineni bestiininten Service-Provider und deni Karleninhaber dienen, und daB 

das Durchfuhren von Transaklionen das Schreiben und/oder Lesen von Daten in das bzw. aus deiii Transferfeld und/ 
Oder das Schreiben und/oder Lesen von Daten in den bzw. aus dent Wertspeicher unifaRt. 

10. Chipkarlc nach eineni der vorhergehenden Anspriiche, dadurch gekennzeichnei, daB sie temer unitaBt: 

eine Einrichlung zuni Durchfuhren von Transaklionen sowohl zwischen einzelnen Teilsirukiuren (VAS-Applikalio- lo 
nen) als auch zwischen einer Teilstruklur und eineni Service-Provider. 

11. Chipkarte nach eineni der vorhergehenden Anspriiche, dadurch gekennzeichneU daB 

der Systeni-Schlussel (Kgo) nur deni Systenihetreiber (System Operator SO) hekannt isr und ein kartenindivi dueller 
und/oder Datensiruktur-( VAS- Container)- spezifischer Schlussel ist, und daB 

die weiteren ini Definiiionsdatensatz enthaltenen Schliisscl kartenindividuelle und/oder Datenstruktur-(VAS-Con- 15 
tainer)-spezifische Schlussel sind. 

12. Chipkarte nach eineni der vorhergehenden Anspriiche, dadurch gekennzeichnei, daB der Definitionsdatensatz 
eines oder mehrere der folgenden Merkniale aufweist: 

eine die Datenstruktur spezifizierende Identifikationsnuniiner (EF_ID) ein Verzeichnis der in der Daienstruktur ent- 
haltenen Teilslrukturen (EF_DIR), wobei das Verzeichnis teilstrukturspezifische Identifikationsnumniem von in der 20 
Datenstruktur (VAS-('ontainer) geladenen Teilslrukturen (VAS-AppHkationen) enlhalt, sowie Infomiationen iiber 
den Teil der Datenstruktur (VAS-Conlainer), in dem die Teilslrukturen (VAS-Appiikalionen) physikalisch gespei- 
chert sind; 

eine Versionsnuminer der Datenstruktur (EF_ VERSION) . 

13. Chipkarte nach eineni der vorhergehenden Anspriiche, dadurch gekennzeichnei, daB sie niindestens eines der 25 
folgenden Merkniale unifaBl: 

cine Einrichlung zur Durchfiihrung eines Entnahnicvorgangs (Take), miltcls dcsscn Daten aus dem Transfcrspci- 
cher entnonimen und/oder entwertet werden; 

eine Einrichlung zur Erzeugung eines oder mehrerer Echtheitsmerkmale der Daten bei Entnahme bzw. der Entwer- 
tung von Daten aus dem Transferspeicher. 30 

14. Chipkarte nach einein der vorhergehenden Anspriiche, dadurch gekennzeichnei, daB die Chipkarte zur Gene- 
rierung der Echtheitsmerkmale folgendes aufweist: 

einen Signierschlussel K^jq vasc "^^^^ Erzeugen einer digilalen Signatur iiber den entnommenen Daten; 

eine Einrichlung zur Erzeugung einer die Transaktion kennzeichnenden Transaktionsnummer, die zur Erzeugung 

der digitalen Signatur mitverwendet wird. 35 

15. Chipkarte nach einem der vorhergehenden Anspriiche, dadurch gekennzeichnei, daB der Signierschliissel 
KsiG VASC einem privaten Key-Generating- Key abgeleiteler privaler Schliissel ist und zur Uberprufung der 
Signatur durch die Serviceprovider offenlliche Schliissel herangezogen werden. 

16. Chipkarte nach eineni der vorhergehenden Anspriiche, dadurch gekennzeichnei, daB sie niindestens eines der 
folgenden Merkniale umfaBl: 40 
eine Einrichlung zur Erzeugung von terminal- und teilstrukturspezifischen Schliisseln (Kdec) niine^ls des Schlussel- 
erzeugungs-Schliissels (KCK^g^-); 

eine Einrichlung zur Verifizierung der RechtmaBigkeil und/oder der Absicherung einer Transaktion unler Verwen- 

dung mindestens eines der folgenden Merkniale: 

des terminal- und teilstrukturspezifischen Schlussels (Ki^^c)' 

des mindestens einen Aulhentifizierungsschlussels (K^yp), 

des mindestens einen Systemschliissels (K^o)^ 

des mindestens einen teilstrukturspezifischen Schlussels (Klvasp- ^^RVASp)* 
des SignierschlUssels (K^jq vasc)' 

der PIN, ~ 50 

der Kennung einer Teilstruklur, 
der Kennung eines Tenninals. 

17. Chipkarte nach einem der vorhergehenden Anspriiche, dadurch gekennzeichneU daB die Chipkarte ferner min- 
destens eines der folgenden Merkmale umfaBl: 

eine Einrichlung zum Authentifizieren der Berechligung und/oder des Terminals mittels des Authentifizierungs- 55 
schlussels bevor ein Lese- oder Schreibvorgang gestartet wird, 

eine Einrichlung zur Durchfiihrung von Lese- oder Schreibvoigangen, die mil einer digitalen Unterschrift und/oder 
Verschliisselung gesicherl sind, 

18. Chipkarte nach einem der vorhergehenden Anspruche, dadurch gekennzeichnei, daB die Chipkarte ferner min- 
destens eines der folgenden Merkmale umfaBl: <iO 
eine Einrichlung zum Aklivieren und Deaktivieren des PIN-Schutzes, 

eine Einrichlung zum Abandem der PIN. 

19. Chipkarte nach einem der vorhergehenden Anspruche, dadurch gekennzeichnei, daB 

die Datenstruktur gemaB einem der vorhergehenden Anspruche von der Kartenpiattfomi unabhangig ist und die 
Chipkarte ferner umfaBl: 65 
eine Einrichlung zum Ubertragen der Datenstruktur oder von Teilen der Datenstruktur auf eine andere Karte. 

20. Chipkarte, dadurch gekennzeichnei, daB sie folgendes aut-weist: 

einen Speicherbereich zum Schreiben oder Lesen von Daten in den oder aus dem Speicherbereich zum Transfer von 

27 
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geldwerten Einheilen und/oder von anderen nichl-inonetaren Anspriichc reprasendercnden Werldaten zwischen 
idenlischen oder unlcrschiedlichen Service-Pro videm. 

21. Temiinal zur Verwendung mil einer Chipkarte geniaB einem dcr Anspriiche 1 bis 20, dadurch gckennzeichnet, 
daB das Temiinal unifaBt: 

5 eine Einrichtiing ziiiii Identifizieren der Datenslniktiir (VAS-Container) der Chipkarte sowie zur Idcntifikation der 

die Dalenstruktur idcnlifiziercnden Kennung (Container-ID); 
und daB es femer mindestens eines der foigenden Merkniale umfaBt: 

eine Einrichtung zuni Lesen von Daten aus mindestens einer der Teilstrukluren und/oder dein Definitionsdatensatz 
und/oder dem Translerspeicher der Karte; 
10 eine Einricht ung zuni Schreiben von Daten in den Trans ferspeic her der Kane; 

eine Einrichtung zuin Laden der zur Durchfiihrung von Transaktionen cribrderlichen Daten in mindestens eine der 
Teilstrukturen (VAS-Applikationen) der Karte. 

22. Tenninal nach Anspruch 21 , dadurch gekennzeichnet, daB es ferner mindestens eines der foigenden Merkmale 
aufweist: 

15 eine Einrichtung zur Durchfiihrung von Transaktionen zwischen einem Service- Provider und dem Karteninhaber, 

wobei das Durchfiihren einer Transaktion mindestens einen der foigenden Schritle umfaBt: 
das Schreiben von Daten in den Wertspeicher, 
das Schreiben von Daten in den Trans ferspeic her, 

das Entnehmen und/oder Entwerten von Daten aus dem Transferspeicher, 
20 das Lesen von Daten aus der Teilstruktur, 

das Lesen von Daten aus dem Transferspeicher. 

23. Tenninal nach einem der Anspriiche 21 oder 22, dadurch gekennzeichnet, daB es ferner umfaBt: 

eine Einrichtung zur Verifizierung der RechtmaBigkeit und/oder der Absicherung einer Transaktion unter Verwen- 
dung mindestens eines der foigenden Merkmale: 
25 eines tenninal- und teilstrukturspezifischen Schlussels (Kdec)' 

des mindestens einen kartenindividuellen oder datenstrukLur-(DF_VAS)-spezirischen Authentifizierungsschliissels 
(Kaut)' 

des mindestens einen kartenindividuellen oder datenstruktur-(DF VAS)-spezifischen Systemschliissels (K^q), 
des mindestens einen teilstrukturspezifischen Schlussels (KlvasP' ^^rvasp)^ 
30 des kartenindividuellen oder datenstruktur-(DF_VAS)-spezifischen Signierschlussels (K^jg vasc)> 

der kartenindividuellen oder datenstruktur-(DF_VAS)-spezifischen PIN, 
der applikationsspezifischen Kennung einer Teilstruktur, 
der terminalspezifischen Kennung eines Terminals, 

24. Terminal nach einem der Anspriiche 219 bis 23, dadurch gekennzeichnet, daB die Einrichtung zum Schreiben 
35 von Daten in den Transferspeicher aufweist: 

eine Einrichtung zum Verschlusseln von Daten unter Verwendung eines terminal- und teilstrukturspezifischen 
Schlussels (Kf^Ec) zum Nachweis der Schreibberechtigung. 

25. Terminal nach einem der Anspriiche 21 bis 24, dadurch gekennzeichnet, daB es ferner aufweist: 

eine Einrichtung zum Durchfiihren eines Entnahmevorgangs von Daten aus dem Transferspeicher, mittels dessen 
40 Daten aus dem Transferspeicher entnommen und/oder entwertet werden. 

26. Tenninal nach einem der Anspriiche 21 bis 25, dadurch gekennzeichnet, daB es ferner mindestens eines der foi- 
genden Merkmale aufweist; 

eine Einrichtung zum Kennzeichnen von Daten des Transferspeichers als entnommen, 
eine Einrichtung zum Kennzeichnen von Daten des Transferspeichers als verf alien. 
45 27. Tenninal nach einem der Anspriiche 21 bis 26, dadurch gekennzeichnet, daB die Einrichtung zum Durchfiihren 

von Transaktionen mindestens eines der foigenden Merkmale aufweist: 
eine Einrichtung zum Andem von Wertdaten in der Teilstruktur; 

eine Einrichtung zum Durchfiihren von Transaktionen zwischen verschiedenen Service-Providem (Interservices) 
auf Kosten bzw. zum Nutzen des Karteninhabers. 

50 28. Tenninal nach einem der Anspriiche 21 bis 27, dadurch gekennzeichnet, daB es ferner aufweist: 

eine Einrichtung zum Authentifizieren der Berechtigung des Terminals gegeniiber der Karte und/oder der Karte ge- 
geniiber dem Tenninal unter Verwendung mindestens eines Authentifizierungsschliissels; 
eine Einrichtung zum Absichem einer Transaktion durch den Karteninhaber mittels einer PIN; 
eine Einrichtung zum Aktivieren und Deaktivieren des PIN-Schutzes. 

55 29. Tenninal nach einem der Anspriiche 21 bis 28, dadurch gekennzeichnet, daB es ferner mindestens eines der foi- 

genden Merkmale aufweist: 

eine Einrichtung zum Ubertragen einer terminalspezifischen Kennung an die Karte; 
eine Einrichtung zum Ubertragen einer die Teilstruktur spezifizierenden Kennung an die Karte; 
eine Einrichtung zum Authentifizieren der Berechtigung unter Veru'endung eines terminal- und teilstrukturspezifi- 
60 schen vSchliissels sowie der temiinal- und teilstrukturspezifischen Kennung, 

eine Einrichtung zur Durchfiihrung von Lese- oder Schreibvorgangen, die mit einer digitalen Unterschrift und/oder 
Verschliisselung gesichert sind, 

30. Tenninal nach einem der Anspriiche 21 bis 29, dadurch gekennzeichnet, daB es ferner mindestens eines der foi- 
genden Merkmale aufweist: 
65 eine Einrichtung zum Selektieren einer Teilstruktur (VAS-Appfikation); 

eine Einrichtung zum Ansehen einer Teilstruktur auf dem Tenninal; 
eine Einrichtung zum Ansehen der Daten einer Teilstruktur auf dem Tenninal; 
eine Einrichtung zum Laden einer Teilstruktur (VAS-Applikation) auf die Karte; 

28 
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einc Einrichtung zuni Laden ciner Kennung einer gcladencn Teilsiruklur (VAS-Applikalion) auf die Karle, 
einc Einrichtung zuni Lose hen einer Teilsiruktur von der Kane; 

eine Einrichtung zuin Substit uiercn ciner Teilstruktur durch eine anderc Teilsiruktur; 
eine Einrichtung zuni Ubertragen einer Teilsiruktur aut^eine andere Karte; 

eine Einrichtung zuni Inlerpretieren einer Teilstruktur beziiglich ihrer Funktion und ihres zugeordneten Service- 5 
Providers sowie xuin Lesen und Ansehen von in ihr gespeicherten Infonnationen. 

3 1 . Verfahren zuni Durchl uhren von Transaktionen zwischen eineni Karteninhaber und iiiindestens eineiii Service- 
Provider unter Verwendung einer Chipkarle sowie eines Teniiinals, wobei das Verrahren einen der folgcnden 
Schriltc uml'al.'it : 

Vorsehen einer auf der Chipkarle abgespeichertcn Dalensiruklur, in die zur Eniioglichung der Durchfuhrung der to 
Transaktion zwischen deiii Karteninhaber und eineni Service-Provider erforderliche Daten (VAS-Daten) geladen 
werden konnen, sowie Schreiben oder Lesen von Daten in die/aus der Datenstruktur (VAS-Applikation); 
Vorsehen eines Transfer-Speicherbereichs (EF_TR ANSFKR) zur Aufnahnie von bei der Durchfuhrung der Trans- 
aktion auszutauschenden oder vorzuweisenden die Geldwerteeinheiten oder nicht-nionetaren Anspruche reprasen- 
tierenden Daten, sowie Schreiben von Daten in den Transferspeicher oder Lesen von Daten aus deni Transferspei- 15 
cher. 

32. Verfahren nach Anspruch 31, dadurch gekennzeichnet, daB das Verfahren niindestens einen der folgcnden 
Schritte umfaBt: 

Verwendung einer Chipkarte geniaB eineni der Anspruche 1 bis 20; 

Verwendung eines Terminals geniafi eineni der Anspruche 21 bis 30; 20 
Schreiben oder Lesen von Daten in den/aus dem Wertspeicher oder Intcm-Speicher oder Info-Speicher von niinde- 
stens einer der Teilstxukturen (VAS-Applikationen). 

33. Verfahren nach Anspruch 31 oder 32, dadurch gekennzeichnet, daB es femer inindestens einen der folgcnden 
Schritte umfaBt: 

Authenlifizieren der Berechtigung des Terminals und/oder der Chipkarte unter Verwendung mindestens eines 25 
Schlussels; 

Absichcm der Transaktion durch Verwendung einer digitalcn Unlcrschrifl und/oder Verschlusselung durch Verwen- 
dung mindestens eines Schlussels. 

34. Verfahren zum Laden von Daten auf eine Chipkarle unter Verwendung eines Terminals, dadurch gekennzeich- 
net, daB das Verfahren mindestens einen der folgcnden Schritte unifaBl: 30 
Laden von Daten in eine Teilstruktur (VAS-Applikation) der Karte; 

Schreiben von Daten in den Definilionsdatensalz der Karle. 

35. Verfahren zum Laden von Daten nach Anspruch 34, welches niindestens einen der tblgenden Schritte unifaBl: 
Verwendung einer Chipkarte geniafi eineni der Anspruche 1 bis 20; 

Verwendung eines Terminals gemiiB eineni der Anspruche 21 bis 30. 35 

36. System zur Durchfuhrung von Transaktionen, gekennzeichnet durch: 
eine Chipkarte gemaB einem der Anspruche 1 bis 20 und 

ein Tenninal gemaB einem der Anspruche 21 bis 30. 
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